clang++ -print-file-name

[tse-gratis]

/raven/bin/clang++ -print-file-name='XX'

For libc++.a This gives /raven/bin/../lib/libc++.a

I could canonicalize the path in zig, but it would be much nicer if this could be in clang... (This is where the ziglang port is currently stuck)

For libc.a This gives /usr/lib/libc.a

This is still with /raven/bin/clang++. Could clang be changed to output /raven/share/raven/sysroot/DragonFly/usr/lib/libc.a? Or /raven/..., or is the /usr/... path correct?

For libgcc_s.so This correctly gives /raven/toolchain/gcc8/lib/libgcc_s.so

For libgcc.a This just gives libgcc.a

Am I right in assuming these should be tidied up in clang?????? Would that be possible? Otherwise I will need to put some hacks to work around this into zig

[tse-gratis]

Ah sorry, I realize I don't understand what's going on quite. It looks like libgcc.a is not being found, but the /usr/lib/libc.a is probably correct

But also zig is execing a cxx compiler with -print-file-name= to find these libraries; so it's probably not even clang++, it's probably the system c++

So the canonicalization is probably not the issue. But whether I do: /raven/share/raven/toolchain/gcc8/bin/c++ -print-file-name='libc++.a' Or /usr/bin/c++ -print-file-name='libc++.a'

I still only get libc++.a in reply, which suggests neither are managing to find it

Clang does find it, but none of the compilers find everything, so there's probably no clean solution. Let me see if I can switch zig to use clang for library path lookups

[jrmarino]

Ideally, only ports actually requiring llvm for some specific reason should be using clang over the port compiler. if zig builds with gcc somewhere else, then it should build with gcc 8.3 here.

[tse-gratis]

Thanks. Then the current blocking issue for zig is that it expects > /raven/share/raven/toolchain/gcc8/bin/gcc -print-file-name='libc++.a' to be able to find libc++.a

I have it installed at /raven/lib. /raven/bin/clang can find it, but /raven/.../gcc cannot

I could get zig to skip this step, and hardcode the path. Would you prefer me to go with that, or would it be nicer to patch gcc to be able to find libc++.a?

[jrmarino]

libc++.a is an llvm product, no? The gcc c++ library is called libstdc++ Seems your configuration script is hardcoding llvm libraries (which is probably an error)

[tse-gratis]

Thanks. Your reply solved the issue