Problem linking with C shared library on linux

help
1

having troubles linking libfmod.so files on linux:

  = note: ld.lld: error: unable to find library -llibfmodL
          ld.lld: error: unable to find library -llibfmodstudioL
          collect2: error: ld returned 1 exit status

//build.rs
    #[cfg(all(not(feature = "debug"), target_os = "linux"))]
    println!("cargo:rustc-link-lib=libfmod");

    #[cfg(all(feature = "debug", target_os = "linux"))]
    println!("cargo:rustc-link-lib=libfmodL");

    #[cfg(all(feature = "studio", feature = "debug", target_os = "linux"))]
    println!("cargo:rustc-link-lib=libfmodstudioL");

    #[cfg(all(feature = "studio", not(feature = "debug"), target_os = "linux"))]
    println!("cargo:rustc-link-lib=libfmodstudio");

it works on windows just fine

root
  hecs //crate
  fmod-sys //crate(also contains duplicates libfmodL.so and etc)
  src
  libfmodL.so.12.11
  fmod.dll //windows only dlls
  ...etc

it links fine on windows though... all the lib files are in the root of the project..... idk why it cant find it... when it can on windows. On this note, the FMOD sound library comes with .libs and .dlls while the linux ones comes with only .so.12.11 files and .so being a symbolic link to those so i just renamed the .so.12.11 ones.

Here is the minimum reproducible case
https://github.com/jestarray/fmod_linking_test/blob/main/fmod-sys/build.rs

2

The lib prefix is implied on linux. Change your printlns to cargo:rustc-link-lib=fmod etc.

3

Alright I removed them and it still couldn't find it. I tried uncommenting:

    let dir = env::var("CARGO_MANIFEST_DIR").unwrap();

    println!("cargo:rustc-link-search={}", dir);

and now it's saying:

target/debug/fmod_linking_test: error while loading shared libraries: libfmodstudioL.so.12: cannot open shared object file: No such file or directory

I don't know why but fmod included these as symbolic links

lrwxrwxrwx   16 a  8 Aug 18:06 libfmod.so -> libfmod.so.12.11
lrwxrwxrwx   16 a  8 Aug 18:06 libfmod.so.12 -> libfmod.so.12.11
.rwxrwxrwx 1.6M a  8 Aug  9:31 libfmod.so.12.11
.rwxrwxrwx 1.9M a  8 Aug  9:31 libfmodL.so.12
lrwxrwxrwx   22 a  8 Aug 18:06 libfmodstudio.so -> libfmodstudio.so.12.11
lrwxrwxrwx   22 a  8 Aug 18:06 libfmodstudio.so.12 -> libfmodstudio.so.12.11
.rwxrwxrwx 1.6M a  8 Aug  9:31 libfmodstudio.so.12.11
lrwxrwxrwx   23 a  8 Aug 18:06 libfmodstudioL.so -> libfmodstudioL.so.12.11
lrwxrwxrwx   23 a  8 Aug 18:06 libfmodstudioL.so.12 -> libfmodstudioL.so.12.11
.rwxrwxrwx 2.4M a  8 Aug  9:31 libfmodstudioL.so.12.11

I tried getting rid of the symbolic link files and just renaming the files it points to, to the said thing but it still no luck..

4

I think you're linking/compiling fine now, and that's a runtime error, in the loader

Your issue seems similar/the same as Call functions from a relative path lib.so/dll - #2 by Yandros and Linking Rust application with a dynamic library not in the runtime linker search path - Stack Overflow

Either set the LD_LIBRARY_PATH, use an rpath, or put the .so dylibs in a folder already in your loader's search path

2 Likes
5

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.