I see Big Sur has put all the system provided libraries, including libc, into a built in dynamic linker cache. For some reason this cache is not visible to ld. This means using ld with -lc does not work as it used to.
There is a work around where you can use -L to add a path to the copy of the libraries that come with XCode, but does that mean anyone who wants to use the compiled program will need to have XCode installed?
Even if XCode is not required, I was wondering; what is the official Apple approved method for a C program to link against a library in the new dynamic linker cache?
It seems to me that ld with -lc should do this automatically. But if the official answer is to use dlopen, then how does a command line C application call dlopen unless it can link against the system library to gain access to dlopen?
What am I not understanding about the new way of doing things?
There is a work around where you can use -L to add a path to the copy of the libraries that come with XCode, but does that mean anyone who wants to use the compiled program will need to have XCode installed?
Even if XCode is not required, I was wondering; what is the official Apple approved method for a C program to link against a library in the new dynamic linker cache?
It seems to me that ld with -lc should do this automatically. But if the official answer is to use dlopen, then how does a command line C application call dlopen unless it can link against the system library to gain access to dlopen?
What am I not understanding about the new way of doing things?
Most folks compile C programs using the compiler driver. For example:
If you want to compile each file separately, you can use the compiler driver for that too:
If you want to explicitly run the linker, you’ll need to tell it what SDK to use. A good way to work out the exact syntax is to run the compiler driver with -v:
The ‘secret sauce’ here is -syslibroot.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
Code Block % sw_vers ProductName: macOS ProductVersion: 11.0.1 BuildVersion: 20B29 % xcode-select -p /Applications/Xcode.app/Contents/Developer % cat test.c #include <unistd.h> const unsigned char pmessagebuf[13] = "hello world\n"; int main (int argc, char* argv[]) { write(STDOUT_FILENO, (void*)pmessagebuf, 12); return(0); } % cc test.c -o test % ./test hello world
If you want to compile each file separately, you can use the compiler driver for that too:
Code Block % rm test % cc -c test.c % cc test.o -o test % ./test hello world
If you want to explicitly run the linker, you’ll need to tell it what SDK to use. A good way to work out the exact syntax is to run the compiler driver with -v:
Code Block % cc test.o -v -o test Apple clang version 12.0.0 (clang-1200.0.32.27) Target: x86_64-apple-darwin20.1.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -lto_library /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib -dynamic -arch x86_64 -platform_version macos 11.0.0 11.0 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -o test -L/usr/local/lib test.o -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/12.0.0/lib/darwin/libclang_rt.osx.a
The ‘secret sauce’ here is -syslibroot.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
