[cfe-dev] Changing the way Clang's driver computes the library search paths on Linux

[Chandler Carruth]

On Sun, Oct 2, 2011 at 11:44 AM, David Chisnall <csdavec at swan.ac.uk> wrote:

> > I'm still happy for you to propose patches using -B, but they need to not
> break existing use cases.
>
> It would help if you told me WHAT didn't work with my last patch.  I added
> = to the start of a couple of paths.  If -B is not specified, then this
> should have no effect.  If -B is specified and the searched-for files do not
> exist in that location, then it should still have no effect...


When -B was not specified, there was an '=' prefixing those paths as handed
to the linker. You can see this by running clang with '-###'. That's why I
checked in the test case I did afterward. Also, when -B is not specified,
GCC does the exact same thing, passing the '=' prefixed paths down to the
linker.

>From my commit message that did the revert:

The manual pages for 'ld' on Linux mention translating a '=' at the
> beginning of the path into a *configure time* sysroot prefix (this is,
> I believe, distinct from the --sysroot flag which 'ld' also can
> support). I tested this with a normal binutils 'ld', a binutils 'ld'
> with the sysroot flag enabled, and gold with the sysroot flag enabled,
> and all of them try to open the path '=/lib/../lib32', No translation
> occurs.

I think at the very least inserting an '=' needs to be conditioned on
> some indication that it is supported and desired. I'm also curious to
> see what toolchain and whan environment cause it to actually make
> a difference.


 As you can see, just inserting a '=' prefix isn't viable. There needs to be
some conditioning or some translation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20111003/1819e11c/attachment.html>