[cfe-users] Building clang with "relative incldue paths"

Matthias Maier tamiko+LLVM at kyomu.43-1.org
Thu Feb 13 05:32:45 PST 2014

Am 13. Feb 2014, 13:52 schrieb Kevin Ingwersen <ingwie2000 at googlemail.com>:

> Hello there.
> I would like to embed clang into one of my projects, a more automated
> build system. Since I prefer Clang over GCC, I would like to use
> it. But for that to work properly, I would need to change the order of
> folders that are searched for libs and includes by default, so it
> would look similar to:
> 	- /path/to/clang/../includes
> 	- /usr/include
> 	- …
> That is, because the tool comes with some pre-compiled libraries and
> their headers - so i want those to be seen before the system ones.

I do not understand. Every path you specify by either -I or -L takes
precedence over system paths. Can you give a precise example on what is
going wrong?

Please also note that the clang driver mimics the gcc frontend very
closely, so I'm surprised that there could be a noticable difference.

You can examine in detail by invoking clang with the "-v" switch,
e.g. on my system it reads:

 $ clang -v -I/tmp/project/include -c test.c

    #include "..." search starts here:
    #include <...> search starts here:

> What config option can I pass to have that work? I see that clang does
> that in the apple toolchain, and no matter where I place it, the path
> to the binary is always correct. So I guess its able to resolve the
> full path to itself, and then append the relative path to the
> includes, or libs.

Currently, the low level toolchain include paths are more or less
compiled statically into the executable, so there is (almost) no way to
either alter or mimic it.


More information about the cfe-users mailing list