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

[Arnaud Allard de Grandmaison]

I think we have a least to distinct cases here. From a distribution
(debian, ...) point of view, it makes sense to have libc++ installed as
part of the OS / System root. On the other hand, if we want that our binary
releases can be used to bootstrap latest llvm versions, we'd prefer not to
depend on some misc libc++ found in the system, but use the one bundled
with the binary release.

Cheers,
--
Arnaud


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

> On Tue, Jan 21, 2014 at 2:20 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
> >
> > 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.
>
>
> Opened http://llvm.org/bugs/show_bug.cgi?id=18569
>
> >
> >
> > 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.
>
> What if Clang installation is not in the system root, but we simply
> provide fresh Clang
> to bootstrap using -DCMAKE_C_COMPILER=/usr/funky/path/bin/clang ?
> Chances are I don't understand --sysroot thing properly. Or do you
> suggest to add additional
> flags to Clang when we configure the build tree with LLVM_ENABLE_LIBCXX ?
>
> >
> >
> > 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
>
>
>
> --
> Alexey Samsonov, MSK
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140121/3b205764/attachment.html>