Link with the dependencies of rust-core #351
Conversation
When linking against a static library you must explicitly link against the dependencies of that static library. These are the libraries which rust itself links against to create libdeltachat.so, you can see this using `readelf -d libdeltachat.so`. The interesting thing is that all these libraries are actually part of your libc. And depending on which libc and which version of libc you use, some symbols may be available without extra linking. So many people would not have noticed these missing links. There is no need to try to detect exactly which links are needed since the loading only happens lazily anyway, so needlessly linking against a lib which should always be available anyway is fairly harmless.
|
I found this while supporting static linking in the python bindings as well, and the CI failed there making me discover this. Here's the relevant commit I'm copying: deltachat/deltachat-core-rust@4d24ce8 |
|
It's failing on mac: |
|
oh great, more random system-specific exceptions. also dcc-rs doesn't get tested on osx? Sounds like another bug. Anyway, I don't have a mac so could someone with a mac look at which libs are used in libdeltachat.dylib (or whatever .so is called there)? |
|
Do you mean this? /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1349.95.0) |
|
Yes, thanks @nicodh! |
When linking against a static library you must explicitly link against
the dependencies of that static library. These are the libraries
which rust itself links against to create libdeltachat.so, you can see
this using
readelf -d libdeltachat.so. The interesting thing isthat all these libraries are actually part of your libc. And
depending on which libc and which version of libc you use, some
symbols may be available without extra linking. So many people would
not have noticed these missing links. There is no need to try to
detect exactly which links are needed since the loading only happens
lazily anyway, so needlessly linking against a lib which should always
be available anyway is fairly harmless.