Building clang from source and header/library, > search paths

Hi Edward, Hans,

Date: Tue, 17 Dec 2013 15:35:24 -0800
From: Hans Wennborg<hans@chromium.org>
To: Edward Diener<eldlistmailingz@tropicsoft.com>
Cc: cfe-dev<cfe-dev@cs.uiuc.edu>
Subject: Re: [cfe-dev] Building clang from source and header/library
  search paths
Message-ID:
  <CAB8jPheVPLhTLjQov2POD1ACd=8NQQHLP_NeLxsXGWFZ7E1E9Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Hi Edward,

>When clang is built on a Linux distro from the latest source as
>described byhttp://clang.llvm.org/get_started.html how are the default
>header and library search paths determined ?

I don't know exactly how it works, but the code that tries to find the
headers and libraries is in lib/Driver/ToolChains.cpp. It's entirely
possible that it gets things wrong on some systems.

Yeah, this happens in GCCInstallationDetector::init() and Linux::Linux(). Perhaps your distro has a nonstandard gcc-triple for your target that Clang doesn't know about yet? (anymore?)

I'm not sure how the --with-gcc-toolchain configuration option is
hooked up, though.

When you specify a <path> with this option, GCCInstallationDetector looks for an appropriate crtbegin.o in paths roughly like:
<path>/lib/gcc/<triple>/<gccversion>/crtbegin.o
and then Linux::Linux() derives paths for headers and libraries from there.

  - Hans

Jon

Edward,

Hi Edward, Hans,

Date: Tue, 17 Dec 2013 15:35:24 -0800
From: Hans Wennborg<hans@chromium.org>
To: Edward
Diener<eldlistmailingz@tropicsoft.com>
Cc: cfe-dev<cfe-dev@cs.uiuc.edu>
Subject: Re: [cfe-dev] Building clang from source and header/library
    search paths
Message-ID:
    <CAB8jPheVPLhTLjQov2POD1ACd=8NQQHLP_NeLxsXGWFZ7E1E9Q@mail.gmail.com>

Content-Type: text/plain; charset=UTF-8

Hi Edward,

>When clang is built on a Linux distro from the latest source as
>described byhttp://clang.llvm.org/get_started.html how are the default
>header and library search paths determined ?

I don't know exactly how it works, but the code that tries to find the
headers and libraries is in lib/Driver/ToolChains.cpp. It's entirely
possible that it gets things wrong on some systems.

Yeah, this happens in GCCInstallationDetector::init() and
Linux::Linux(). Perhaps your distro has a nonstandard gcc-triple for
your target that Clang doesn't know about yet? (anymore?)

I am running this on Mageia 3.

Running "clang++ -v -x c++ /dev/null" for packaged clang 3.2 version the
shows this header path:

#include <...> search starts here:
/usr/lib/gcc/x86_64-mageia-linux-gnu/4.7.2/../../../../include/c++/4.7.2
/usr/lib/gcc/x86_64-mageia-linux-gnu/4.7.2/../../../../include/c++/4.7.2/x86_64-mageia-linux-gnu
/usr/lib/gcc/x86_64-mageia-linux-gnu/4.7.2/../../../../include/c++/4.7.2/backward
/usr/local/include
/usr/bin/../lib/clang/3.2/include
/usr/include

while running "./clang++ -v -x c++ /dev/null" for the built clang 3.5
version the shows this header path:

#include <...> search starts here:
/usr/local/include
/home/mgeldiener/dev/clang/build/Debug+Asserts/bin/../lib/clang/3.5/include
/usr/include

In other words the built 3.5 version does not find the
'/usr/lib/gcc/x86_64-mageia-linux-gnu/4.7.2' path off of which the gcc
headers reside. Is there a way to fix that when building the latest
version of clang from the source without having to change any source
files ? Is there a reason why building the latest version does not find
the 'gcc triple' whereas the packaged 3.2 version of clang does find it ?