Continuing the discussion from Disadvantages of preferring dynamic linking in debug mode?:
What happens if they actually depend on different versions of that library?
Unless I'm missing something, this strictly should be possible: you simply get two copies of the statically linked code loaded. This happens all the time with libraries like zlib.
If I had to guess why you might run into issues, there's a couple of things:
- Export name collisions. If the common rlib exports anything from the dynamic libraries, then I'll bet that the platform linker will get confused when trying to resolve the names. Perhaps only if you actually import them. Shouldn't be an issue if you're manually loading them though.
- Logical issues where you're trying to share objects across the common library instances, and it gets confused because it didn't see where that one came from. Especially common in C with FILE* instances shared between dynamic libraries when the standard library is statically linked.
Both of these essentially require that the common library is part of the public interface. If it isn't, then there's no logical reason there should be an issue, as far as I know.
Rustc explicitly prevents you from using two dylibs together that include the same rust crate to prevent the issues you mention.
If it did when the common crate was not publicly exposed, is there still a chance of breakage? It's probably not a good idea, but logically it shouldn't cause issues.
For symbol conflicts it could still be an issue. For duplicate state it depends on the crate. It may depend on another shared library and expect that the state of itseld and said shared library is synced for example which would be false in case of duplicates.
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.