[cfe-dev] driver search paths and library discovery.

[Justin Bogner]

Iain Sandoe <iain at codesourcery.com> writes:
> 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.