r199632 - Make the Linux support for finding libc++ somewhat less braindead.
Alexey Samsonov
samsonov at google.com
Tue Jan 21 02:09:01 PST 2014
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.
>
>>
>>>
>>> Would it make sense to move libc++.so to lib/clang/3.5/lib/linux/?
>>
>>
>> This is a good question.
>>
>> Historically, GCC has considered libstdc++ to be "part of" the compiler or
>> toolchain, and distributed them together. We lookup libstdc++ out of GCC's
>> installation tree for example.
>>
>> Also historically, libc++ has *not* been distributed as "part of" the
>> compiler or toolchain. On OS X it is actually more part of the OS than the
>> toolchain. Even on Linux, some care has been taken to try to make it
>> effective to use libc++ with a GCC host just as much as with a Clang host.
>>
>> I'm not trying to endorse either of these approaches, but that's what they
>> have been historically. To my mind, that makes lib/clang/<version>
>> inapropriate for libc++. If we want to switch to shipping libc++ as merely
>> an implementation detail of Clang itself, then I would suggest installing
>> *both* headers and libraries under lib/clang/<version>. But that would be a
>> reasonably radical departure from current trends etc.
>
> I see, lib/clang is not a good choice then.
>
>>
>>>
>>>
>>> On Mon, Jan 20, 2014 at 7:23 PM, Alexey Samsonov <samsonov at google.com>
>>> wrote:
>>> > Hi Chandler,
>>> >
>>> > Fixing include paths is not enough - you should also fix library
>>> > lookup paths for dynamic linker in Clang driver. Currently if the
>>> > build tree has both Clang binary and built libc++ like this:
>>> > <...>/bin/clang++
>>> > <...>/lib/libc++.so
>>> >
>>> > Clang binary is not able to locate libc++.so with -stdlib=libc++
>>> > provided. Therefore the following brute-force bootstrap process
>>> > wouldn't work:
>>> > (1) configure a new build tree with default options and build Clang and
>>> > libc++
>>> > (2) configure a new build tree with just-built Clang as c/c++ compiler
>>> > and specify LLVM_ENABLE_LIBCXX=ON
>>> >
>>> > I'll try to take a closer look at this (and potentially fix the
>>> > driver) tomorrow, unless someone who has more understanding picks it
>>> > up from here.
>>> >
>>> >
>>> >
>>> > On Mon, Jan 20, 2014 at 1:42 PM, Chandler Carruth <chandlerc at gmail.com>
>>> > wrote:
>>> >> Author: chandlerc
>>> >> Date: Mon Jan 20 03:42:24 2014
>>> >> New Revision: 199632
>>> >>
>>> >> URL: http://llvm.org/viewvc/llvm-project?rev=199632&view=rev
>>> >> Log:
>>> >> Make the Linux support for finding libc++ somewhat less braindead.
>>> >>
>>> >> Now instead of just looking in the system root for it, we also look
>>> >> relative to the clang binary's directory. This should "just work" in
>>> >> almost all cases. I've added test cases accordingly.
>>> >>
>>> >> This is probably *very* worthwhile to backport to the 3.4 branch so
>>> >> that
>>> >> folks can check it out, build it, and use that as their host compiler
>>> >> going forward.
>>> >>
>>> >> Modified:
>>> >> cfe/trunk/lib/Driver/ToolChains.cpp
>>> >> cfe/trunk/test/Driver/linux-header-search.cpp
>>> >>
>>> >> Modified: cfe/trunk/lib/Driver/ToolChains.cpp
>>> >> URL:
>>> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp?rev=199632&r1=199631&r2=199632&view=diff
>>> >>
>>> >> ==============================================================================
>>> >> --- cfe/trunk/lib/Driver/ToolChains.cpp (original)
>>> >> +++ cfe/trunk/lib/Driver/ToolChains.cpp Mon Jan 20 03:42:24 2014
>>> >> @@ -2945,9 +2945,24 @@ void Linux::AddClangCXXStdlibIncludeArgs
>>> >>
>>> >> // Check if libc++ has been enabled and provide its include paths if
>>> >> so.
>>> >> if (GetCXXStdlibType(DriverArgs) == ToolChain::CST_Libcxx) {
>>> >> - // libc++ is always installed at a fixed path on Linux currently.
>>> >> - addSystemInclude(DriverArgs, CC1Args,
>>> >> - getDriver().SysRoot + "/usr/include/c++/v1");
>>> >> + const std::string LibCXXIncludePathCandidates[] = {
>>> >> + // The primary location is within the Clang installation.
>>> >> + // FIXME: We shouldn't hard code 'v1' here to make Clang future
>>> >> proof to
>>> >> + // newer ABI versions.
>>> >> + getDriver().Dir + "/../include/c++/v1",
>>> >> +
>>> >> + // We also check the system as for a long time this is the only
>>> >> place Clang looked.
>>> >> + // FIXME: We should really remove this. It doesn't make any
>>> >> sense.
>>> >> + getDriver().SysRoot + "/usr/include/c++/v1"
>>> >> + };
>>> >> + for (unsigned i = 0; i <
>>> >> llvm::array_lengthof(LibCXXIncludePathCandidates);
>>> >> + ++i) {
>>> >> + if (!llvm::sys::fs::exists(LibCXXIncludePathCandidates[i]))
>>> >> + continue;
>>> >> + // Add the first candidate that exists.
>>> >> + addSystemInclude(DriverArgs, CC1Args,
>>> >> LibCXXIncludePathCandidates[i]);
>>> >> + break;
>>> >> + }
>>> >> return;
>>> >> }
>>> >>
>>> >> @@ -2971,7 +2986,7 @@ void Linux::AddClangCXXStdlibIncludeArgs
>>> >> MIPSABIDirSuffix, DriverArgs, CC1Args))
>>> >> return;
>>> >>
>>> >> - const std::string IncludePathCandidates[] = {
>>> >> + const std::string LibStdCXXIncludePathCandidates[] = {
>>> >> // Gentoo is weird and places its headers inside the GCC install,
>>> >> so if the
>>> >> // first attempt to find the headers fails, try these patterns.
>>> >> InstallDir.str() + "/include/g++-v" + Version.MajorStr + "." +
>>> >> @@ -2984,8 +2999,9 @@ void Linux::AddClangCXXStdlibIncludeArgs
>>> >> LibDir.str() + "/../include/c++",
>>> >> };
>>> >>
>>> >> - for (unsigned i = 0; i <
>>> >> llvm::array_lengthof(IncludePathCandidates); ++i) {
>>> >> - if (addLibStdCXXIncludePaths(IncludePathCandidates[i],
>>> >> + for (unsigned i = 0; i <
>>> >> llvm::array_lengthof(LibStdCXXIncludePathCandidates);
>>> >> + ++i) {
>>> >> + if (addLibStdCXXIncludePaths(LibStdCXXIncludePathCandidates[i],
>>> >> TripleStr + MIPSABIDirSuffix +
>>> >> BiarchSuffix,
>>> >> DriverArgs, CC1Args))
>>> >> break;
>>> >>
>>> >> Modified: cfe/trunk/test/Driver/linux-header-search.cpp
>>> >> URL:
>>> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/linux-header-search.cpp?rev=199632&r1=199631&r2=199632&view=diff
>>> >>
>>> >> ==============================================================================
>>> >> --- cfe/trunk/test/Driver/linux-header-search.cpp (original)
>>> >> +++ cfe/trunk/test/Driver/linux-header-search.cpp Mon Jan 20 03:42:24
>>> >> 2014
>>> >> @@ -1,6 +1,29 @@
>>> >> // General tests that the header search paths detected by the driver
>>> >> and passed
>>> >> // to CC1 are sane.
>>> >> //
>>> >> +// Test a simulated installation of libc++ on Linux, both through
>>> >> sysroot and
>>> >> +// the installation path of Clang.
>>> >> +// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
>>> >> +// RUN: -target x86_64-unknown-linux-gnu \
>>> >> +// RUN: -stdlib=libc++ \
>>> >> +// RUN: -ccc-install-dir %S/Inputs/basic_linux_tree/usr/bin \
>>> >> +// RUN: --sysroot=%S/Inputs/basic_linux_libcxx_tree \
>>> >> +// RUN: | FileCheck --check-prefix=CHECK-BASIC-LIBCXX-SYSROOT %s
>>> >> +// CHECK-BASIC-LIBCXX-SYSROOT: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
>>> >> +// CHECK-BASIC-LIBCXX-SYSROOT: "-isysroot" "[[SYSROOT:[^"]+]]"
>>> >> +// CHECK-BASIC-LIBCXX-SYSROOT: "-internal-isystem"
>>> >> "[[SYSROOT]]/usr/include/c++/v1"
>>> >> +// CHECK-BASIC-LIBCXX-SYSROOT: "-internal-isystem"
>>> >> "[[SYSROOT]]/usr/local/include"
>>> >> +// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
>>> >> +// RUN: -target x86_64-unknown-linux-gnu \
>>> >> +// RUN: -stdlib=libc++ \
>>> >> +// RUN: -ccc-install-dir %S/Inputs/basic_linux_libcxx_tree/usr/bin
>>> >> \
>>> >> +// RUN: --sysroot=%S/Inputs/basic_linux_libcxx_tree \
>>> >> +// RUN: | FileCheck --check-prefix=CHECK-BASIC-LIBCXX-INSTALL %s
>>> >> +// CHECK-BASIC-LIBCXX-INSTALL: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
>>> >> +// CHECK-BASIC-LIBCXX-INSTALL: "-isysroot" "[[SYSROOT:[^"]+]]"
>>> >> +// CHECK-BASIC-LIBCXX-INSTALL: "-internal-isystem"
>>> >> "[[SYSROOT]]/usr/bin/../include/c++/v1"
>>> >> +// CHECK-BASIC-LIBCXX-INSTALL: "-internal-isystem"
>>> >> "[[SYSROOT]]/usr/local/include"
>>> >> +//
>>> >> // Test a very broken version of multiarch that shipped in Ubuntu
>>> >> 11.04.
>>> >> // RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
>>> >> // RUN: -target i386-unknown-linux \
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> cfe-commits mailing list
>>> >> cfe-commits at cs.uiuc.edu
>>> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>> >
>>> >
>>> >
>>> > --
>>> > Alexey Samsonov, MSK
>>> > _______________________________________________
>>> > cfe-commits mailing list
>>> > cfe-commits at cs.uiuc.edu
>>> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>> _______________________________________________
>>> cfe-commits mailing list
>>> cfe-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>>
--
Alexey Samsonov, MSK
More information about the cfe-commits
mailing list