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
Am Do. Feb. 13 2014 14:32:45 schrieb Matthias Maier:
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.
>
> Am 13. Feb 2014, 13:52 schrieb Kevin Ingwersen <ingwie2...@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:
> /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
> _______________________________________________
> cfe-users mailing list
> cfe-users@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-users
_______________________________________________
cfe-users mailing list
cfe-users@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-users
