search

libbitcoin / libbitcoin-explorer

Bitcoin Command Line Tool
Other
600 stars 176 forks source link

`--disable-shared` doesn't work #677

Closed secinthenet closed 3 years ago

secinthenet commented 3 years ago

I reproduced this in debian stable with Docker in https://github.com/libbitcoin/libbitcoin-explorer/pull/676

Steps to reproduce (you need that PR):

docker build -t bx .
docker run --rm -it --entrypoint=bash bx ldd /usr/local/bin/bx

Output:

        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)
evoskuil commented 3 years ago

Since it works in all of the CI builds I encourage you to find out what is different.

secinthenet commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

You could modify the test execution to run a smoke test on binaries. The pull request for that would verify linkage in CI.

secinthenet commented 3 years ago

The produced bx binary 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 commented 3 years ago

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 commented 3 years ago

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 ldd show 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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Closed for lack of activity. Feel free to open a PR with resolution!