Building clang with "relative incldue paths"

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.

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.

How can I achieve this?

Kind regards, Ingwie! ^^

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:
     /tmp/project/include
     /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include/g++-v4
     /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include/g++-v4/x86_64-pc-linux-gnu
     /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include/g++-v4/backward
     /usr/bin/../lib/clang/3.4/include
     /usr/include

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.

Best,
Matthias

Hey.

Thanks for your fast response!

Yep, I know about the -v option to look at what Clang is doing, and that is exactly where I saw something thet interested me - i’ll highlight what i mean.

Ingwie@Ingwies-Air /tmp $ nano test.c
Ingwie@Ingwies-Air /tmp $ cat test.c
int main() { return 0; }
Ingwie@Ingwies-Air /tmp $ clang -v test.c
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix
“/Applications/drag0n/drag0n.app/Contents/System/usr/bin/clang” -cc1 -triple x86_64-apple-macosx10.9.0 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name test.c -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 224.1 -v -resource-dir /Applications/drag0n/drag0n.app/Contents/System/usr/bin/…/lib/clang/5.0 -fdebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 272 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.9.0 -fobjc-dispatch-method=mixed -fobjc-default-synthesize-properties -fencode-extended-block-signature -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/sd/6zp4rxhs61xcp5ymdd5_fgq80000gn/T/test-dKNjJ0.o -x c test.c
clang -cc1 version 5.0 based upon LLVM 3.3svn default target x86_64-apple-darwin13.0.0
#include “…” search starts here:
#include <…> search starts here:
/usr/local/include
/Applications/drag0n/drag0n.app/Contents/System/usr/bin/…/lib/clang/5.0/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
“/Applications/drag0n/drag0n.app/Contents/System/usr/bin/ld” -demangle -dynamic -arch x86_64 -macosx_version_min 10.9.0 -o a.out /var/folders/sd/6zp4rxhs61xcp5ymdd5_fgq80000gn/T/test-dKNjJ0.o -lSystem /Applications/drag0n/drag0n.app/Contents/System/usr/bin/…/lib/clang/5.0/lib/darwin/libclang_rt.osx.a

Yep, I „stole“ the apple toolchain to another folder, because I was making an experiment with it. And at that point, I noticed that it was looking into a relative path as well as absolute paths.

My question was, how can I add my own relative path to the list?
Is it some configure/Cmake option that I can pass?

Kind regards,
Ingwie.