A short while ago, I was working on some test-code which uses -nostdlib but requires that the libclang_rt.osx.a is used to provide some built-in support. Essentially, a requirement to be able to find the relevant libclang_rt.a for the compiler-under-test.
On OS X (at least) it seems that:
clang -print-search-dirs
produces a single library path pointing to the resource dir. That is, it points neither to the "lib" dir containing dylibs nor to the <resource>/lib/darwin/ dir which contains the lib<clang,compiler>_rt.a.
This means that
clang -print-file-name=libclang_rt.osx.a fails,
whereas:
clang -print-file-name=lib/darwin/libclang_rt.osx.a suceeds.
Jim and I were chatting about this on irc, but couldn't come up with a reason why it's done this way - can you shed some light?
A short while ago, I was working on some test-code which uses
-nostdlib but requires that the libclang_rt.osx.a is used to provide
some built-in support. Essentially, a requirement to be able to find
the relevant libclang_rt.a for the compiler-under-test.
On OS X (at least) it seems that:
clang -print-search-dirs
produces a single library path pointing to the resource dir. That is,
it points neither to the "lib" dir containing dylibs nor to the
<resource>/lib/darwin/ dir which contains the
lib<clang,compiler>_rt.a.
This means that
clang -print-file-name=libclang_rt.osx.a fails,
whereas:
clang -print-file-name=lib/darwin/libclang_rt.osx.a suceeds.
Jim and I were chatting about this on irc, but couldn't come up with a
reason why it's done this way - can you shed some light?
The issue with finding libclang_rt isn't Darwin specific, and our
behaviour looks like a bit of an accident of history to me. Clang's
implementation of -print-search-dirs and -print-file-name with respect
to the resource dir is very much based on what gcc does - but gcc puts
libraries at the top level of that directory whereas clang embeds them
under a lib/ subdirectory.
Notably, the search path needs to have the resource dir, and you can see
that -print-file-name=include has the expected behaviour. In gcc, this
happens to also be the directory where compiler runtime stuff (libgcc)
lives, but in clang we need to traverse to ./lib/darwin or ./lib/linux
or whatever there.
I guess we should probably add that to the search dirs. Anyone have a
reason not to?
You also point out that the path to the various "lib" dirs with dylibs
are missing on Darwin. I'm not really sure why that is.