I'm getting the following error when I try to execute my make file:
clang: error: cannot specify -o when generating multiple output files
The issue occurred when I upgraded to Mac OSX Mavericks (Xcode 5.0.1). I have spent days trying to figure this problem out on the forums, and I'm just very lost. After deleting a previous XCode version, I reinstalled a clean one (from the Mac App Store). When I ran the following:
sudo port install gcc49
It froze trying to build libgcc-devel.
Any help as I'm desperate, working on dissertation work.
(Answered in the comments. See Question with no answers, but issue solved in the comments (or extended in chat) )
When the OP wrote:
readPVCData: readPVCData.o readfunc.o readlib.h
gcc -o readPVCData readPVCData.o readfunc.o readlib.h -lm -lsndfile
readPVCData.o: readPVCData.c readlib.h
gcc -c readPVCData.c
readfunc.o: readfunc.c readlib.h
gcc -c readfunc.c
#Kevin wrote:
Pretty sure your problem is the readlib.h in gcc -o readPVCData readPVCData.o readfunc.o readlib.h -lm -lsndfile. Take it out.
Related
When I try to compile my eek.cpp file with g++ eek.cpp -o eek -fsanitize=undefined flag, it shows:
ld: library not found for -lubsan
collect2: error: ld returned 1 exit status
but g++ eek.cpp -o eek is working fine.
My terminal screenshot here.
I'm using zsh and gcc 10.2.0 on macOS Big Sur. fsanitize=undefined was still working yesterday before I updated my macOS from Catalina.
The ubsan.h file does exist in /usr/local/Cellar/gcc/10.2.0_2/lib/gcc/10/gcc/x86_64-apple-darwin20/10.2.0/plugin/include, but it isn't working.
I've also read this post but it didn't solve my problem. How should I fix it?
I've had the same problem since I updated my macOS, but have just now fixed with brew upgrade.
I'm sorry that I can't say what formula was involved in this problem, but updating formulae would be worth trying.
I had similar problem when trying to compile a fortran program and getting the error ld: librarynot found for -lSystem. The answer of #kaage helped me but I don't have enough reputation to comment it.
I just wanted to add that when running brew upgrade it complained that my command line tools were too outdated. Running (as suggested by brew itself)
sudo rm -rf /Library/Developer/CommandLineTools
sudo xcode-select --intsall
fixed it.
Not sure this perfectly targets the question asked though so feel free to correct me.
I'm on a mac and I used homebrew to install gmp.
Kyumins-iMac:gcjlib math4tots$ g++ main.cpp -lgmp -lgmpxx
In file included from main.cpp:2:
./gcjlib.hpp:4:10: fatal error: 'gmpxx.h' file not found
#include <gmpxx.h>
^
1 error generated.
So then I explicitly told g++ to use /usr/local/include
Kyumins-iMac:gcjlib math4tots$ g++ main.cpp -lgmp -lgmpxx -I/usr/local/include
ld: library not found for -lgmp
clang: error: linker command failed with exit code 1 (use -v to see invocation)
So then I explicitly told g++ to use /usr/local/lib
Kyumins-iMac:gcjlib math4tots$ g++ main.cpp -lgmp -lgmpxx -I/usr/local/include -L/usr/local/lib
Kyumins-iMac:gcjlib math4tots$ ./a.out
sum is -4444
absolute value is 4444
So the only issue seems to be that g++ fails to acknowledge /usr/local.
But it is tedious to type all this out all the time, especially when I'm just writing small single file programs.
Is there a way for me to get g++ to acknowledge the stuff in /usr/local by default? Is there a standard way homebrew users do this?
I'm on OS X 10.9.3 with Xcode 5.1.1 in case it is relevant.
I also use Homebrew and had a similar problem on Mac OSX Maverick 10.9.5 and Xcode 6.0.1, but it was solved by running:
xcode-select --install
Note that it doesn't work without the double hyphens given by the previous answer. This installs the command-line tools that also create /usr/lib/ and /usr/include/. I don't know why Homebrew doesn't automatically check this upon installation, since it does check for Xcode...
If you want to check exactly what folders your compiler is looking through for header files you can write:
cpp -v
A workaround would be to:
export C_INCLUDE_PATH=/usr/local/include
export CPLUS_INCLUDE_PATH=/usr/local/include
At least this tricked the pre-processor to behave here :)
Try running xcode-select --install
At least on Mavericks, I've found that if I install the Xcode application without installing the command-line tools, then the tools are sort of available, but normal unix-ey builds don't work correctly. One symptom is that /usr/local/include is not on the include search path. The command-line tools seem to resolve this issue.
I have Yosemite 10.10.5 and running xcode-select --install didn't fix the problem for me. The command returned with xcode-select: error: command line tools are already installed, use "Software Update" to install updates.
When I ran xcode-select -p, it showed /Applications/Xcode.app/Contents/Developer. I ended up deleting Xcode from the Applications directory, which resulted in xcode-select -p returning /Library/Developer/CommandLineTools. This fixed compiler error for me.
That was helpful for me:
Use the latest version. 1.0.2o_1 just a current build.
brew install openssl
ln -s /usr/local/Cellar/openssl/1.0.2o_1/include/openssl /usr/local/include/openssl
ln -s /usr/local/Cellar/openssl/1.0.2o_1/lib /usr/local/lib/openssl
There are a few questions around this topic with answers that suggest putting a symlink in /usr/local/include. However I'm running macOS Monterey 12.3 (on an M1 MacBook) and that directory doesn't exist.
I had installed the Xcode command line tools by downloading the package from Apple, so xcode-select --install just tells me it's already installed and doesn't create any directories.
I ran cpp -v to see which directories are searched for #include <...>:
/Library/Developer/CommandLineTools/usr/lib/clang/13.1.6/include
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
/Library/Developer/CommandLineTools/usr/include
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)
I picked /Library/Developer/CommandLineTools/usr/include for the symlink. In that directory, I ran the following command (note the new location for Homebrew installations, under /opt/homebrew - some old answers are also out of date on this point):
sudo ln -s /opt/homebrew/opt/openssl#3/include/openssl .
clang was then able to find the OpenSSL files.
apk add --no-cache build-base
it works fine ！！！！
go build -tags musl -o main main.go
Following the guide over at http://www.scratchapixel.com/lessons/3d-basic-lessons/lesson-2-get-started/get-started/ and I got down to the part where you set up GLFW. Everything was going fine got CMake all installed properly and it went through the process just as shown on the images on the site. Everything installed fine to the /usr/local/include and /usr/local/lib folders. So the next thing to do is test that it installed fine and every time I try to do anything with whats in the glfw folder, gives me this error:
fatal error: 'GLFW/glfw3.h' file not found
These are the commands I've tried to run it with:
gcc boing.c -o boing
gcc -lglfw boing.c -o boing
gcc -lglfw3 boing.c -o boing
gcc -I/usr/local/include boing.c -o boing (different error)
The last one almost worked and gave several different errors, which I think may have been caused by something else. That's kind of besides the point though. What am I doing wrong here? To my knowledge gcc is meant to look in the /usr/local/include folder by default for libraries.
The issue I'm having is that gcc (and family) don't appear to be properly setup. I have a 10.7.4 machine that I just installed Xcode on (from the app store). I've done no prior development on this machine.
Working w/in Xcode seems to work fine. I can build and compile no problem. However, trying to execute gcc command line fails.
First, I gcc wasn't on my path ... no big deal. I located it and ran as:
/Applications/Xcode.app/Contents/Developer/usr/bin/gcc -dynamiclib -fno-common -o s.dylib s.c
(I'm working on a lib w/some functions...). Anyways, it fails.
s.c:1:19: error: stdio.h: No such file or directory
s.c:2:20: error: stdlib.h: No such file or directory
s.c:3:20: error: string.h: No such file or directory
Surprise! hah, well I searched my machine for stdio.h and I can't find it anywhere. Since I've been out of the OSX game for a bit, I'm assuming I'm missing something -
Basically I want to be able to continue using Xcode but I want to be able to build C/C++/etc on the command line with all the dependencies (.h) in the correct place.
Any thoughts?
There are two main ways to run the compiler from the command line: the Command Line Tools package, and xcrun.
xcrun is particularly good if you just need this occasionally. Just stick "xcrun" at the start, like you'd do with sudo:
xcrun gcc -dynamiclib -fno-common -o s.dylib s.c
This will find the correct version of gcc and set the needed directories, etc. You can specify a specific SDK with --sdk.
If you do this a lot, download and install the Command Line Tools package (Xcode>Open Developer Tool>More Tools...; it also may be available in Preferences>Downloads). This installs a full copy of everything in /usr.
Probably xcrun is not enough if you are using 10.8.
Looking in to the clang documentation I found that you need to include the system root because you do not have your libraries in the standard place but inside Xcode.
using:
xcrun gcc -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk
or:
xcrun clang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk
I'm having trouble building MySQLdb on Mac OSX Mountain Lion. After upgrading to OSX Mountain Lion from OSX Lion, I have downloaded and installed Xcode 4.4 also. Then, I went to Preference > Downloads of the Xcode and installed Command Line Tools.
I've downloaded MySQL-python ver. 1.2.3 from http://sourceforge.net/projects/mysql-python/
When I run
python setup.py build
I get below message:
running build
running build_py
copying MySQLdb/release.py -> build/lib.macosx-10.6-intel-2.7/MySQLdb
running build_ext
building '_mysql' extension
gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -g -O2 -DNDEBUG -g -O3 -Dversion_info=(1,2,3,'final',0) -D__version__=1.2.3 -I/usr/local/mysql/include -I/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c _mysql.c -o build/temp.macosx-10.6-intel-2.7/_mysql.o -Os -g -fno-common -fno-strict-aliasing -arch x86_64
unable to execute gcc-4.2: No such file or directory
error: command 'gcc-4.2' failed with exit status 1
However, the gcc exists. When I run
gcc
I get
i686-apple-darwin11-llvm-gcc-4.2: no input files
Below is a similar question that I have found but its solution, which is exactly what I have done already, doesn't work for me.
How to install MySQLdb on Mountain Lion
I've had a similar problem while working with Ruby On Rails 3.2.7.
I too had upgraded the system to Mountain Lion, installed Xcode 4.4.1 and downloaded the Command Line Tools.
On the command line I got an error message saying it was impossible to find the file: /usr/bin/gcc-4.2 (I can't paste the precise output right now, I'm sorry).
I did have a /usr/bin/gcc and its version was i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1
I solved the problem by symlinking the file in the same directory and giving it the name the Ruby script was looking for:
sudo ln -s /usr/bin/gcc /usr/bin/gcc-4.2
After that, everything worked fine.
Use the following command to make make (or similiar) use the correct gcc:
export CC=/usr/bin/gcc
I ran into this. For me it was because I installed python from a DMG installer at http://python.org . Those are built against the wrong gcc. I fixed it by compiling python from source using Homebrew: Link
brew install python
That links against the correct gcc
(In my specific case I was using an older Python which is why I had used a DMG installer. I discovered that homebrew also has formulas for older versions)
I detoured this problem by using ActivePython.
There's specific installation instruction for MySQLdb here.
Since this is the first time I've used ActivePython I'm not sure if this' a robust solution for this problem. Therefore, I will leave this question open until I make sure this works.