Static linking and RDB/Rados

Static linking and RDB/Rados

[Beierl, Mark]

I’ve been doing some playing around with static linking and from the looks of it the static libraries for Rados and RDB are no longer available.  Same goes for some of the libraries needed to enable HTTP (S3) support.

So, I don’t think the options for –build-static are valid anymore.  If anyone has pointers as to how to get the static Rados or RDB libraries, I’d love to hear about it :)

Regards,
Mark
 
Mark Beierl
SW System Sr Principal Developer
Dell EMC | Cloud & Communication Service Provider Solution
Mark.Beierl@Dell.com

Re: Static linking and RDB/Rados

[Sitsofe Wheeler]

Hi,

On Fri, 26 Oct 2018 at 00:53, Beierl, Mark <Mark.Beierl@dell.com> wrote:
>
> I’ve been doing some playing around with static linking and from the looks of it the static libraries for Rados and RDB are no longer available.  Same goes for some of the libraries needed to enable HTTP (S3) support.
>
> So, I don’t think the options for –build-static are valid anymore.  If anyone has pointers as to how to get the static Rados or RDB libraries, I’d love to hear about it :)

You didn't mention your distro but I think in the case of curl (which
is used for the HTTP/S3 suport) it will be highly environment
dependent. For example, Ubuntu seem to ship a static version of
libcurl (https://packages.ubuntu.com/bionic/amd64/libcurl4-gnutls-dev/filelist
and see libcurl-gnutls.a) but I can't see any static libcurl in
regular Fedora packages. In fact, I know that Fedora doesn't ship a
static libaio either and others have been forced to download the
source, build a private copy with a static library and then point fio
at that in they wanted such a binary on Fedora.

-- 
Sitsofe | http://sucs.org/~sits/

Re: Static linking and RDB/Rados

[Beierl, Mark]

> On Oct 26, 2018, at 00:12, Sitsofe Wheeler <sitsofe@gmail.com> wrote:
> 
> 
> [EXTERNAL EMAIL] 
> Please report any suspicious attachments, links, or requests for sensitive information.
> 
> 
> Hi,
> 
>> On Fri, 26 Oct 2018 at 00:53, Beierl, Mark <Mark.Beierl@dell.com> wrote:
>> 
>> I’ve been doing some playing around with static linking and from the looks of it the static libraries for Rados and RDB are no longer available.  Same goes for some of the libraries needed to enable HTTP (S3) support.
>> 
>> So, I don’t think the options for –build-static are valid anymore.  If anyone has pointers as to how to get the static Rados or RDB libraries, I’d love to hear about it :)
> 
> You didn't mention your distro but I think in the case of curl (which
> is used for the HTTP/S3 suport) it will be highly environment
> dependent. For example, Ubuntu seem to ship a static version of
> libcurl (https://packages.ubuntu.com/bionic/amd64/libcurl4-gnutls-dev/filelist
> and see libcurl-gnutls.a) but I can't see any static libcurl in
> regular Fedora packages. In fact, I know that Fedora doesn't ship a
> static libaio either and others have been forced to download the
> source, build a private copy with a static library and then point fio
> at that in they wanted such a binary on Fedora.
> -- 
> Sitsofe | http://sucs.org/~sits/

Thanks, Sitsofe. 

Sorry about that. I tried Alpine, Ubuntu 16.04 and 18.04, as well as CentOS 7. No luck with any of them. It also seems that I was going down some rabbit hole with nghttp2, which also seems to be missing the .a static library. I think most distros are moving away from shipping static libraries now. 

My goal is to create a statically linked FIO that I can use on different targets without having to recompile on each. I’m no longer sure that this is even a good thing, because if the distro maintainers are dropping static libraries, there must be a good reason. 

Having said that, if I do get a docker build with all the static sources and a final FIO statically built, would the community be interested in this?  I could propose a patch with this as a dockerfile if so and then others with experience in different areas might be able to help. 

Re: Static linking and RDB/Rados

[Beierl, Mark]

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

Regards,
Mark
 
Mark Beierl
SW System Sr Principal Developer
Dell EMC | Cloud & Communication Service Provider Solution
Mark.Beierl@Dell.com

On 2018-10-26, 07:02, "fio-owner@vger.kernel.org on behalf of Beierl, Mark" <fio-owner@vger.kernel.org on behalf of Mark.Beierl@dell.com> wrote:

    
    [EXTERNAL EMAIL] 
    Please report any suspicious attachments, links, or requests for sensitive information.
    
    
    
    
    > On Oct 26, 2018, at 00:12, Sitsofe Wheeler <sitsofe@gmail.com> wrote:
    > 
    > 
    > [EXTERNAL EMAIL] 
    > Please report any suspicious attachments, links, or requests for sensitive information.
    > 
    > 
    > Hi,
    > 
    >> On Fri, 26 Oct 2018 at 00:53, Beierl, Mark <Mark.Beierl@dell.com> wrote:
    >> 
    >> I’ve been doing some playing around with static linking and from the looks of it the static libraries for Rados and RDB are no longer available.  Same goes for some of the libraries needed to enable HTTP (S3) support.
    >> 
    >> So, I don’t think the options for –build-static are valid anymore.  If anyone has pointers as to how to get the static Rados or RDB libraries, I’d love to hear about it :)
    > 
    > You didn't mention your distro but I think in the case of curl (which
    > is used for the HTTP/S3 suport) it will be highly environment
    > dependent. For example, Ubuntu seem to ship a static version of
    > libcurl (https://packages.ubuntu.com/bionic/amd64/libcurl4-gnutls-dev/filelist
    > and see libcurl-gnutls.a) but I can't see any static libcurl in
    > regular Fedora packages. In fact, I know that Fedora doesn't ship a
    > static libaio either and others have been forced to download the
    > source, build a private copy with a static library and then point fio
    > at that in they wanted such a binary on Fedora.
    > -- 
    > Sitsofe | http://sucs.org/~sits/
    
    Thanks, Sitsofe. 
    
    Sorry about that. I tried Alpine, Ubuntu 16.04 and 18.04, as well as CentOS 7. No luck with any of them. It also seems that I was going down some rabbit hole with nghttp2, which also seems to be missing the .a static library. I think most distros are moving away from shipping static libraries now. 
    
    My goal is to create a statically linked FIO that I can use on different targets without having to recompile on each. I’m no longer sure that this is even a good thing, because if the distro maintainers are dropping static libraries, there must be a good reason. 
    
    Having said that, if I do get a docker build with all the static sources and a final FIO statically built, would the community be interested in this?  I could propose a patch with this as a dockerfile if so and then others with experience in different areas might be able to help. 
    

Re: Static linking and RDB/Rados

[Sitsofe Wheeler]

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@dell.com> 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/

Re: Static linking and RDB/Rados

[Beierl, Mark]

On 2018-10-27, 05:54, "Sitsofe Wheeler" <sitsofe@gmail.com> 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@dell.com> 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

Re: Static linking and RDB/Rados

[Sitsofe Wheeler]

On Thu, 8 Nov 2018 at 21:17, Beierl, Mark <Mark.Beierl@dell.com> wrote:
>
>
> On 2018-10-27, 05:54, "Sitsofe Wheeler" <sitsofe@gmail.com> 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@dell.com> 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?

Maybe there needs to be a "--try-static-first" option?

-- 
Sitsofe | http://sucs.org/~sits/