Building a crate with `librna-sys` as a dependency might fail linking against `openmp` about librna-sys HOT 7 OPEN

Hi! Thanks for your help. That was my issue - adding extern crate openmp_sys to my main fixed the build. Thanks for maintaining this useful wrapper and keeping an eye on the repo with your fast responce!

from librna-sys.

related upstream issue: ViennaRNA/ViennaRNA#215

from librna-sys.

Still getting this issue even with librna-sys as a dependency and libsvm downgraded to 3.31. Not sure what further troubleshooting approaches to take

from librna-sys.

Hi @croots! Could you provide further information?
Which version of ViennaRNA are you using? 2.6.4 is already statically linking against a bundled libsvm-3.31. There shouldn't be any need to downgrade.
You said you added librna-sys as a dependency, did you mean openmp-sys?
You should follow the instructions of openmp-sys (i.e. adding extern crate openmp_sys; to your code).

If that still doesn't help, could you share logs containing the specific error messages or a minimal example project reproducing the error?

from librna-sys.

You're welcome!

from librna-sys.

Hey there,
I'm not familiar at all with rust, but wouldn't it make sense to include something like:

cargo:rustc-link-lib=gomp

here?
I'm just wondering, since it appears to be similar to rust-lang/cc-rs#266, and the issue doesn't show up if you use any C/C++ compiler. The RNAlib2.pc file adds the -fopenmp flag to Libs and the C/C++ compilers then automatically link against the correct OpenMP libraries... Maybe this is not happening with the rust compiler?

Let me know if this is an issue that I could resolve at our (ViennaRNA Package) end!

Cheers!

EDIT: It seems you are already using the correct way by adding openmp-sys (https://crates.io/crates/openmp-sys) So, maybe requiring that internally in librna-sys would make sense, if the C library has been build with OpenMP support...

from librna-sys.

@RaumZeit thanks for chiming in! Basically, the remaining issue for me is the decision whether to require openmp-sys internally or not.
If I remember correctly, I didn't do this because it seemed to me that ViennaRNA can be configured without OpenMP support in which case I didn't want to break compilation of librna-sys on systems without OpenMP.

I might have to check the whole linking setup again though. It didn't appear to be a problem with an earlier version of libsvm bundled in ViennaRNA (which the SHAPEwarp people seemed to notice too).

However, I'm not familiar enough with the configuration in ViennaRNA.
E.g. would disabling OpenMP support for ViennaRNA also disable OpenMP support for the bundled libsvm?

Additionally, I'm not sure whether OpenMP is linked statically in ViennaRNA. That could be the reason why the problem didn't occur in librna-sys up to a certain version of ViennaRNA when libsvm was updated?
I.e. is -fopenmp in RNAlib2.pc only necessary for libsvm or does ViennaRNA itself also link dynamically against OpenMP?

If I could determine unambiguously whether libRNA.a dynamically links OpenMP somewhere (be it in ViennaRNA code or libsvm code), I could probably include openmp-sys conditionally in my lib.rs using some build.rs shenanigans.

(Edit) tl;dr: if ViennaRNA unconditionally relies on OpenMP I can simply include openmp-sys as well. Otherwise I should document the solution/workaround in a more prominent location (i.e. README file) and optionally expose a cargo feature for conveniently toggling the desired behavior.

from librna-sys.