r199632 - Make the Linux support for finding libc++ somewhat less braindead.

[Chandler Carruth]

On Tue, Jan 21, 2014 at 2:09 AM, Alexey Samsonov <samsonov at google.com>wrote:

> On Tue, Jan 21, 2014 at 1:12 PM, Evgeniy Stepanov
> <eugeni.stepanov at gmail.com> wrote:
> > On Tue, Jan 21, 2014 at 1:06 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
> >> On Tue, Jan 21, 2014 at 12:06 AM, Evgeniy Stepanov
> >> <eugeni.stepanov at gmail.com> wrote:
> >>>
> >>> I don't this adding builddir/lib to linker search path would be right.
> >>
> >>
> >> Why not?
> >
> > Because at the moment it contains a bunch of host libraries, and
> > libc++ we are trying to link is a target library. Of course, at the
> > moment it is being built with the host compiler, but it is a target
> > library in spirit.
>
> Exactly. Can we build libc++ in somewhere like
> <build-dir>/lib/x86_64-linux-gnu/libc++.so
> instead of <build-dir>/lib/libc++.so as we do now? We can later
> generalize this to build multiple
> versions of libc++ for different target arches, and we can teach Clang
> to look for libc++ in
> a target-specific directory.


Please see my comment that specifically addressed this: this would be a
radical change in how libc++ is built and distributed from its historical
process. We can argue whether that is good or bad, but its absolutely not
something we can change at the drop of a hat yet. I'd at least like
Marshall and some of the BSDs that are currently shipping libc++ to comment
on such a change.

It would be *really* bad if Linux expected libc++ to be part of the
compiler's tree of libraries and headers, but FreeBSD, Darwin, and every
other OS expected it to be part of the OS or system root.


We can fix this issue with a smaller change though. In the same way we
currently check to see if the GCC installation is inside of the requested
system root and add its parent 'lib' directory to the library search paths,
we can check if the Clang installation is inside of the requested system
root and do the same.


If we want to follow the practice of GCC here (which I'm actually of two
minds about, I see both sides) then the correct way to handle this is
likely to build per-target trees. GCC cross compilers install libraries
into <prefix>/<target-triple>/lib (relative to
<prefix>/bin/<target-triple>-gcc). We could do something similar, but I'm
hesitant to go this route without some significant buy in across platforms.
I would really like to have at least some consistency and sanity in how we
build Clang as a cross compiler and libc++ as a standard library targeting
various different platforms.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140121/5bdf1ca2/attachment.html>