On 2018-10-27, 05:54, "Sitsofe Wheeler" <sitsofe@xxxxxxxxx> wrote:
I'm afraid this is a classic Linux issue - trying to ship a binary
that works everywhere is very hard and thus we now have
docker/flatpak/snaps/appimage etc. Outside "app packagers" getting
past what you've seen is likely going to be a lot of work and would
likely involve having to ship all the dynamically libraries and mess
around with LD_LIBRARY (and even then you've had to build everything
on a "suitably old" distro to ensure the dynamic linking works)...
On Fri, 26 Oct 2018 at 22:24, Beierl, Mark <Mark.Beierl@xxxxxxxx> wrote:
>
> Sorry, this is still a no-go for RBD with static linking.
>
> I found a librbd.a in Xenial, but it requires a ton of statically linked libraries to be pulled in along with it:
>
> ldd /usr/lib/x86_64-linux-gnu/librbd.so
> linux-vdso.so.1 => (0x00007ffccd124000)
> librados.so.2 => /usr/lib/x86_64-linux-gnu/librados.so.2 (0x00007faac9be2000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007faac99de000)
> libboost_thread.so.1.58.0 => /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.58.0 (0x00007faac97b8000)
> libboost_random.so.1.58.0 => /usr/lib/x86_64-linux-gnu/libboost_random.so.1.58.0 (0x00007faac95b0000)
> libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007faac936f000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007faac9152000)
> librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007faac8f49000)
> libboost_iostreams.so.1.58.0 => /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.58.0 (0x00007faac8d30000)
> libboost_system.so.1.58.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.58.0 (0x00007faac8b2c000)
> libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007faac87a9000)
> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007faac84a0000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007faac80d6000)
> /lib64/ld-linux-x86-64.so.2 (0x000055ab4535a000)
> libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007faac7ebf000)
> libnss3.so => /nss-3.32/dist/Linux3.10_x86_64_cc_glibc_PTH_64_DBG.OBJ/lib/libnss3.so (0x00007faac7b4a000)
> libsmime3.so => /nss-3.32/dist/Linux3.10_x86_64_cc_glibc_PTH_64_DBG.OBJ/lib/libsmime3.so (0x00007faac7919000)
> libnspr4.so => /usr/lib/x86_64-linux-gnu/libnspr4.so (0x00007faac76d9000)
> libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007faac74d4000)
> libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007faac72c3000)
> libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007faac70a9000)
> libnssutil3.so => /nss-3.32/dist/Linux3.10_x86_64_cc_glibc_PTH_64_DBG.OBJ/lib/libnssutil3.so (0x00007faac6e6f000)
> libplc4.so => /usr/lib/x86_64-linux-gnu/libplc4.so (0x00007faac6c6a000)
> libplds4.so => /usr/lib/x86_64-linux-gnu/libplds4.so (0x00007faac6a66000)
>
> I got most of them, but I cannot find any statically linked libnss3.a. Building that from source [1] turned out to be a nightmare, so I’m at a dead end again.
>
> [1] https://github.com/nss-dev/nss
--
Sitsofe | http://sucs.org/~sits/
Seeing as librbd is no longer available as a static library, what about the following patch to configure, which *always* includes librbd as dynamic, even when a static build is requested?
===================
diff --git a/configure b/configure
index 1f4e50b1..01d5ef57 100755
--- a/configure
+++ b/configure
@@ -1663,8 +1663,12 @@ int main(int argc, char **argv)
return 0;
}
EOF
-if test "$disable_rbd" != "yes" && compile_prog "" "-lrbd -lrados" "rbd"; then
- LIBS="-lrbd -lrados $LIBS"
+if test "$disable_rbd" != "yes" && compile_prog "" "-Wl,-Bdynamic -lrbd -lrados" "rbd"; then
+ if test "$build_static" = "yes" ; then
+ LIBS="-Wl,-Bdynamic -lrbd -lrados -Wl,-Bstatic $LIBS"
+ else
+ LIBS="-lrbd -lrados"
+ fi
rbd="yes"
fi
print_config "Rados Block Device engine" "$rbd"
===================
It violates the request for static, but it isn’t possible with RBD anyway. Thoughts?
Regards,
Mark
