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
Related
I have this strange issue where creating / using a static library works in my Ubuntu VM but not on macOS:
ld: warning: ignoring file ./dist/libXXXX.a, building for macOS-x86_64 but attempting to link with file built for macOS-x86_64
Command to create the static library is:
ar rcs libtest.a obj1.o obj2.o ...
Compiler invocation:
gcc -g -Wall -Wextra main.c -L./dist -lXXXX -o main
Searching on google didn't yield any usable results except for this (maybe) related question on SO:
Possible related question
I realize this is an old post and you found your fix, but let me post this here for anyone else who runs into this problem for whom these answers don't provide a solution.
You might be using two different toolchains unknowingly, one from Apple (installed via Xcode) and one from GNU (installed via Home-brew or MacPorts). If you type ranlib --version and see version info showing that ranlib is GNU, this is likely the case.
Make sure that /usr/bin comes in your $PATH before /usr/local/bin and /opt/local/bin. When you run which -a ranlib, the first result in the list should be /usr/bin/ranlib. Same for which -a ar-- the first result should be /usr/bin/ar. If it is not so, you need to fix your $PATH.
Once you fix your path and clean your project, try building again and things should work.
The issue was solved when I directly put those object files rather than gathering them into a static library, i.e.,
gcc -g -Wall -Wextra main.c obj1.o obj2.o -o main
After that, I got many warnings like ld: warning: object file (obj1.o) was built for newer macOS version (11.0) than being linked (10.14), but it is a warning, and the object is linked, so the problem is solved.
The root cause is that some library passes -mmacosx-version-min=10.14 to gcc, so the object file is built for 10.14, but my macos is now 11.0.
If you want to make things work, try directly using object files rather than creating a static library.
If you want to resolve all the warnings, find ``-mmacosx-version-min` and comment it.
After looking at my script that automatically creates the static library I've found the culprit:
For some reason my tool created object files for header files (resulting in files like header.h.o).
Removing those fixed the issue.
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
I have an OpenGL project which works/compiles fine in Windows.
I wanted to port the application to Mac OS.
I got the application up and running on Mac, but the text inside the project is not visible. So I decided to use a 3rd party library for text rendering in Mac, I came across FreeType, which has many advantages such as anti-aliasing and UNICODE support.
So, I downloaded the library on my Mac, './configure'd it, did 'make' and 'make install' as I would normally do.
Then in Xcode I set search paths for both include and library directories,
/usr/local/include and /usr/local/lib respectively. Then I added 'other linker flags' in Xcode, freetype-configure --libs gave me following flags- -L/usr/local/lib -lfreetype -lz -lbz2, I added them in Xcode.
Now, whenever I include a freetype header there is no problem, but when I call any method from the freetype library, it gives me following linker error.
After looking up on google I found out that I have to set the build targets accordingly, I did that, now my application builds for i386 x86 the issue still persist.
I also tried following flags while configuring freetype ./configure CC="gcc -arch i386" CXX="g++ -arch i386"
which did not help either.
I am relatively new to Mac OS X/Unix environment, I have previously got freetype working on windows with VS 2008. Any help would be greatly appreciated.
What:
It seems you have more than one libfreetype.dylib file in your library search paths.
/master_repository/......../lib contains one and /usr/local/lib contains another
-lfreetype is a convenient way of telling the linker to look for file named libfreetype.dylib in all the directories specified with -L flags. Because -L/master_repository... comes before -L/usr/local/lib in the linker argument list, the linker uses the first instance it finds and attempts linking to that one.
Fix:
Reorganising your -L flags so that -L/usr/local/lib comes before the other. Avoid this option if you can.
Removing the extra search path, leaving only the relevant one.
Specifying the library explicitly instead of relying on the convenient -l by replacing -lfreetype with a full path to a library: /usr/local/lib/libfreetype.dylib
I was trying to install gcc and gfortran on my intel mac with mountain lion and keep getting the above error when trying to compile the fortran file. gcc doesn't seem to work either with c programs. This is the error I get with my c program:
test.c:1:19: fatal error: stdio.h: No such file or directory
I tried typing this into terminal:
export PATH=${PATH}:/usr/local/bin
but that did not work. I added gcc and gfortran to /usr/local/bin instead of /usr/bin. I downloaded the compilers through hpc. The files had the given directory structure:
/usr/local/bin: contained gcc and gfortran along with other compilers
/uer/local/include/...
/usr/local/lib/...
etc...
I pretty much just copied and pasted all the files directly over to the exact same path directories on my computer and ran the export command. That is all I have done.
You probably need either odcctools (as provided by macports) or XCode (which contains the Mac "binutils", and the Clang compiler, GCC was discontinued).
I want to compile a c file in OSX mountain lion. In Xcode 4.4, Preferences -> Downloads I can install command line tools to do that. However on that pane it advises me that I can use xcrun instead:
Before installing, note that from within Terminal you can use the XCRUN tool to launch compilers and other tools embedded within the Xcode application. Use the XCODE-SELECT tool to define which version of Xcode is active. Type "man xcrun" from within Terminal to find out more.
I'd be happy to do it that way, but I'm having trouble getting it to find stdio.h.
$ xcrun gcc hello.c
hello.c:1:19: error: stdio.h: No such file or directory
I definitely have this file on my system after a standard install of Xcode via the App Store:
/Applications/Xcode.app/Contents/Developer//Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/include/stdio.h
I tried specifying the SDK but got the same error:
$ xcrun -sdk /Applications/Xcode.app/Contents/Developer//Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk gcc hello.c
Some googling led me to try running xcode-select before the commands above, but no luck. I only have the one version of Xcode installed anyway.
$ sudo xcode-select -switch /Applications/Xcode.app
How can I get it to find the headers?
Ultimately I gave up and installed command line tools, but it would be nice to know how to do it with the built-in Xcode tools.
Note: here is the file I was trying to compile:
#include <stdio.h>
int main() {
printf("hello world!\n");
return 0;
}
You will have to specify the non-standard sysroot for the compiler.
Using clang/llvm (which is the new standard) this would do the trick:
xcrun clang --sysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/ -o hello hello.c
If you want to stick with gcc just replace "clang" with "gcc".
Probably not of any direct help with this, but you can set up aliases to commonly used xcrun commands so that when other processes call gcc, make, gdb, git and so on that the Xcode versions get used:
alias gcc='xcrun gcc'
You can put the alias into the .bashrc file if you like so that it persists, and source from .bash_profile as necessary.
The advantage of all this is that you don't need to install the Xcode Command Line Tools and can also avoid using package managers, saving space, reducing complexity and taking advantage of Xcode automatically updating these tools for you.
Using xcrun --sysroot was not working for me using 10.8.
Looking in to the clang documentation I found that -isysroot is the option to use in this case.
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
For me it was useful to create the following aliases:
alias xcrungcc='xcrun gcc -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk'
alias xcrunclang='xcrun clang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk'