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 <[email protected]>wrote: > On Tue, Jan 21, 2014 at 2:20 PM, Chandler Carruth <[email protected]> > wrote: > > > > On Tue, Jan 21, 2014 at 2:09 AM, Alexey Samsonov <[email protected]> > > wrote: > >> > >> On Tue, Jan 21, 2014 at 1:12 PM, Evgeniy Stepanov > >> <[email protected]> wrote: > >> > On Tue, Jan 21, 2014 at 1:06 PM, Chandler Carruth < > [email protected]> > >> > wrote: > >> >> On Tue, Jan 21, 2014 at 12:06 AM, Evgeniy Stepanov > >> >> <[email protected]> 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 > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
