[CDRIVER-3941] Attempt to load libbson-1.0.so.0 when statically linked Created: 30/Mar/21  Updated: 27/Oct/23  Resolved: 28/Apr/21

Status: Closed
Project: C Driver
Component/s: None
Affects Version/s: 1.17.4
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Thijs Cadier Assignee: Kevin Albertson
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux



 Description   

I can successfully compile and link When using -DENABLE_STATIC=ON. When running the executable on a different system it still tries to load a dynamic libbson:

error while loading shared libraries: libbson-1.0.so.0: cannot open shared object file: No such file or directory



 Comments   
Comment by Kevin Albertson [ 28/Apr/21 ]

I am glad to hear thijs@appsignal.com! Closing.

Comment by Thijs Cadier [ 28/Apr/21 ]

Thanks for figuring this out. Based on this tip I made a few changes and it now works.

Comment by Kevin Albertson [ 22/Apr/21 ]

Hi thijs@appsignal.com! I was able to reproduce this using a simple Rust project that includes a dependency for mongo_driver on macOS 11.2. The output of otool -l shows the produced target has a dependency on the dylibs:

/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
/usr/local/opt/mongo-c-driver/lib/libmongoc-1.0.0.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/opt/mongo-c-driver/lib/libbson-1.0.0.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/opt/openssl@1.1/lib/libssl.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
/usr/local/opt/openssl@1.1/lib/libcrypto.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1)
/usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0)

I am not too familiar with the Rust build process, but applying this change worked for me:

diff --git a/mongoc-sys/build.rs b/mongoc-sys/build.rs
index 2484003..6643979 100644
--- a/mongoc-sys/build.rs
+++ b/mongoc-sys/build.rs
@@ -15,7 +15,7 @@ fn main() {
     if pkg_config::Config::new()
         .atleast_version(mongoc_version)
         .statik(true)
-        .probe("libmongoc-1.0")
+        .probe("libmongoc-static-1.0")
         .is_err()
         {
             let out_dir_var = env::var("OUT_DIR").expect("No out dir");

The static and non-static package config scripts are separately named. pkg-config --static libmongoc-1.0 is equivalent to pkg-config libmongoc-1.0. To get the static build flags, use pkg-config libmongoc-static-1.0.

Comment by Kevin Albertson [ 19/Apr/21 ]

Thank you for the additional information thijs@appsignal.com. We should have time to attempt to reproduce and investigate this issue this week.

Comment by Thijs Cadier [ 18/Apr/21 ]

Any news on this?

Comment by Thijs Cadier [ 01/Apr/21 ]

You can see the used options here.

I know this option is picked up for mongoc itself correctly. Without this option it will also try to load that dynamically. I think you can reproduce this by compiling statically and trying to use the binary on a system that does not have the dynamic libs installed.

Comment by Kevin Albertson [ 31/Mar/21 ]

Hi thijs@appsignal.com, thank you for the bug report! We will look into this soon.

The cmake option ENABLE_STATIC should enable static libbson / libmongoc targets (libmongoc-static-1.0.a and libbson-static-1.0.a on Unix) to build and install.

How are you configuring and building the application that is using libbson / libmongoc? Can you include the commands you are using to build your application (whether that is using cmake, pkg-config, etc.)

Generated at Wed Feb 07 21:19:27 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.