WebDrake
commented
4 years ago Closed WebDrake closed 4 years ago
WebDrake
commented
4 years ago WebDrake
commented
4 years ago Explicitly specifying the path to the core-snap library locations results in the libraries not being found:
$ ldc2 --link-internally -L-L/snap/core/current/lib/x86_64-linux-gnu hello.d
lld: error: unable to find library -lrt
lld: error: unable to find library -ldl
lld: error: unable to find library -lpthread
lld: error: unable to find library -lm
Error: linking with LLD failedThis is particularly odd, because the libraries in question are indeed present there.
WebDrake
commented
4 years ago (A minor note: using --link-internal also bumps into the ldc2.conf problem described in https://github.com/ldc-developers/ldc2.snap/issues/102, but this we can treat separately.)
WebDrake
commented
4 years ago The same errors happen when using --link-internally with e.g. the upstream 1.20.0 binary package. So this is likely not an issue with the snap package per se.
kinke
commented
4 years ago -link-internally isn't really supposed to work without adding a bunch of linker options otherwise implicitly added by the C compiler for Linux and BSDs, see https://github.com/ldc-developers/ldc/pull/2203#issuecomment-381366375.
WebDrake
commented
4 years ago Thanks for the pointer. One thing I don't quite understand there is the need for the manual -L options given that the linker call does automatically reference the system libraries, e.g. with the current snap package, ldc2 -link-internally -v hello.d results in a linker command:
lld hello.o -o hello -L/snap/ldc2/115/bin/../lib64 -L/snap/ldc2/115/bin/../lib32 --no-warn-search-mismatch -lphobos2-ldc -ldruntime-ldc --gc-sections -lrt -ldl -lpthread -lm
lld: error: unknown argument '--no-warn-search-mismatch'
lld: error: unable to find library -lrt
lld: error: unable to find library -ldl
lld: error: unable to find library -lpthread
lld: error: unable to find library -lm
Error: linking with LLD failedI take it that what's missing are some extra flags referred to in the PR you linked to, but it's not 100% obvious which. Bear in mind that in the above example I'm trying to build for the regular host system, not cross-compiling for ARM.
A regular ldc2 -v hello.d gives this for the GCC linker command:
/usr/bin/gcc hello.o -o hello -fuse-ld=gold -L/snap/ldc2/115/bin/../lib64 -L/snap/ldc2/115/bin/../lib32 -Xlinker --no-warn-search-mismatch -lphobos2-ldc -ldruntime-ldc -Wl,--gc-sections -lrt -ldl -lpthread -lm -m64 ... which isn't very revealing, but ldc2 -v -L-v hello.d gets more detail:
/usr/bin/ld.gold -plugin /usr/lib/gcc/x86_64-linux-gnu/5/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper -plugin-opt=-fresolution=/tmp/ccMbakM2.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --sysroot=/ --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker /lib64/ld-linux-x86-64.so.2 -z relro -o hello /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/5/crtbegin.o -L/snap/ldc2/115/bin/../lib64 -L/snap/ldc2/115/bin/../lib32 -L/usr/lib/gcc/x86_64-linux-gnu/5 -L/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/5/../../.. hello.o -v --no-warn-search-mismatch -lphobos2-ldc -ldruntime-ldc --gc-sections -lrt -ldl -lpthread -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/5/crtend.o /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crtn.oI'll go through this and see if I can come up with a matching list for what's needed here.
Anyway, this clearly isn't a snap package issue. Would some extra upstream docs be welcome/useful at this stage, or is this enough of a moving target that it's best to hold off for now until further technical developments have happened upstream?
kinke
commented
4 years ago There's an open issue about this, and it's unlikely to be supported soon/at all due to the heterogeneous posix environments.
WebDrake
commented
4 years ago Thanks. I've subscribed to the upstream issue, and will close this now.
The following errors result when trying to build a simple "Hello World" with the internal LLD:
This suggests that the internal LLD does not by default have enough info to know where to look for system libraries.
In principle it could use either the host system's libs, or those in the core snap.