Repository navigation
--disable-shared doesn't work #677
Description
I reproduced this in debian stable with Docker in #676
Steps to reproduce (you need that PR):
docker build -t bx .
docker run --rm -it --entrypoint=bash bx ldd /usr/local/bin/bxOutput:
linux-vdso.so.1 (0x00006a7135b76000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00006a71355f2000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00006a71355e8000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00006a71355e3000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00006a713545f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00006a71352dc000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00006a71352c2000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00006a71350ff000)
/lib64/ld-linux-x86-64.so.2 (0x00006a7135b78000)
Activity
evoskuil commentedon Dec 30, 2020
Since it works in all of the CI builds I encourage you to find out what is different.
secinthenet commentedon Dec 31, 2020
How do you know it works there?
It's not that the build fails, it's that the resulting binaries are dynamically linked to libraries. I don't see a test for that in the CI build.
evoskuil commentedon Dec 31, 2020
You’re right, the tests are run against executables that link the same libraries. So this should be sufficient. But I also know that this is the (recommended) build that others are using and haven’t had problems with (including myself). libthread and librt are dependencies on the OS that don’t get statically linked.
evoskuil commentedon Dec 31, 2020
You could modify the test execution to run a smoke test on binaries. The pull request for that would verify linkage in CI.
secinthenet commentedon Dec 31, 2020
The produced
bxbinary does work, it's just not statically linked, so it's not surprising that others didn't have problems with this.For context, I want fully static linking to make it always work when it's used offline in different air gapped scenarios.
BTW, can't libpthread and librt be statically linked as well?
evoskuil commentedon Dec 31, 2020
It is statically linked. You cannot avoid dynamic linking to necessary OS components. I reduced the dynamic linkage to the lowest level possible form the same reason. I’m surprised those components are not present in the OS.
secinthenet commentedon Dec 31, 2020
Why can't you link everything statically?
golang does it, and while I remember it may be tricky in C/C++, it seems possible: https://stackoverflow.com/questions/35116327/when-g-static-link-pthread-cause-segmentation-fault-why
BTW, what does
lddshow on your system? I'm curious why the static linking doesn't work for me (and neither in a docker container, which is a good sign something is wrong and not related to my setup)evoskuil commentedon Dec 31, 2020
Feel free to do it. ldd has always shown OS dependencies, same for Windows and macOS. The binary needs to talk to the OS.
secinthenet commentedon Dec 31, 2020
Yes, but it doesn't have to use a dynamic library to talk to the OS. Again, golang does it, and I've seen it done with C++ too, though it's a bit harder.
Do you see any less libraries on Linux, or is what I'm seeing normal? (see output in original message in the issue)
evoskuil commentedon Dec 31, 2020
Again, feel free to do it. I’m not a Linux guru, so couldn’t find a way. But it didn’t seem necessary. It links on Ubuntu out of the box.
evoskuil commentedon Feb 18, 2021
Closed for lack of activity. Feel free to open a PR with resolution!