Rustc statically links libdl.a rather than dynamic link libdl.sl

help
1

I've worked to understand the internals of the problem I'm having cross-compiling rust for armv7-unknown-linux-gnueabihf. I initially isolated the problem to the compiler output and googled Everywhere with no reason why:

  = note: /home/mike/opt/cross/lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/bin/ld: /home/mike/opt/cross/sysroot/usr/lib/arm-linux-gnueabihf/libdl.a(dladdr.o): in function `dladdr':
          (.text+0x0): undefined reference to `__dladdr'
          collect2: error: ld returned 1 exit status

I added a rustflags = { "-C", "link-arg=-Wl,-Map=link.map",.. and produced this excerpt showing clearly that several libraries have been statically linked.

START GROUP
LOAD C:\Users\mike\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\armv7-unknown-linux-gnueabihf\lib\libstd-fd9999d9af6f6529.rlib
LOAD C:\Users\mike\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\armv7-unknown-linux-gnueabihf\lib\libpanic_unwind-ed6f6440333ce40a.rlib
LOAD C:\Users\mike\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\armv7-unknown-linux-gnueabihf\lib\libunwind-393fb0f7bb39d6d5.rlib
LOAD C:\Users\mike\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\armv7-unknown-linux-gnueabihf\lib\liballoc_system-a339806aa9c9a51f.rlib
LOAD C:\Users\mike\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\armv7-unknown-linux-gnueabihf\lib\liblibc-bd124e237b0f2e77.rlib
LOAD C:\Users\mike\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\armv7-unknown-linux-gnueabihf\lib\liballoc-a6d6146cde3aaae8.rlib
LOAD C:\Users\mike\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\armv7-unknown-linux-gnueabihf\lib\libcore-8002c4b6a877854c.rlib
END GROUP
LOAD C:\Users\mike\.rustup\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\armv7-unknown-linux-gnueabihf\lib\libcompiler_builtins-617fba26869ad15c.rlib
LOAD /home/mike/opt/cross/sysroot/usr/lib/arm-linux-gnueabihf/libdl.a
LOAD /home/mike/opt/cross/sysroot/usr/lib/arm-linux-gnueabihf/librt.a
LOAD /home/mike/opt/cross/sysroot/usr/lib/arm-linux-gnueabihf/libpthread.so
START GROUP
LOAD /home/mike/opt/cross/sysroot/lib/arm-linux-gnueabihf/libpthread.so.0
LOAD /home/mike/opt/cross/sysroot/usr/lib/arm-linux-gnueabihf/libpthread_nonshared.a
END GROUP

I am told in some comment that libdl.a is vestigial and will Only link properly with much older glibc than rust and my RPi are working with. I have tried to reorder the actual gcc invocation to get the linker to pull in the dynamic libdl.so library to no (current) avail.

Can anyone who knows the internals please comment on why+how the GCC link op is being told to statically link libdl and librt (assume it'll be next problem)? Thanks for Any help.

Best regards, Mike

2

Hey, made real progress as I moved past testing rust cargo config and tried directly linking with gcc. Doing this I found that cygwin has some tight specs on how to specify the symlink path with its ln. Also, using 7-zip or any other will Not setup a proper symlink regardless of using administrator privilege. You should carefully check your symlink between usr/lib/arm-linux-gnueabihf/libdl.so points to lib/arm-linux-gnueabihf/libdl-so-2.24.so or your equivalent level library.