Open fncnt opened 11 months ago
related upstream issue: https://github.com/ViennaRNA/ViennaRNA/issues/215
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
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?
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!
You're welcome!
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 https://github.com/rust-lang/cc-rs/issues/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...
@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.
If you use
librna-sys
as a dependency you might encounter an error similar to this:The current solution to this is to add
openmp-sys
as a dependency to your crate as well. I'm currently hesitating to do this internally inlibrna-sys
but that might change in the future.