Menu
Consider the following:
I developed X with the strict requirement to use Y v2.0 for some it's internal business. This is to say that I cannot by any means revert to Y v1.0.
On the other side, the developer has similar restrictions to use Y v1.0.
As you can already argue, the question is: how can I link Y inside X without exporting Y symbols to avoid collisions? Y is well established, and possibly I'd not want to modify its source code or build settings (if publicly available).
To put things more onto Earth, I am in the process of designing an SDK that will for sure need some 3rd party libraries, let's say zlib.
In my development I'll rely on zlib v1.2.3.4.5.rc6 because I extensively and successfully used and tested it, and I cannot afford the SDK testing/fixing required if I change version.
All the statically or dinamically linked libraries the SDK will offer must hide the 3rd party static ones.
The potential customer could undergo similar restrictions (he needs zlib v7.8.9), so how can I avoid symbol collisions? Again, possibly without changing the original source code (namespacing etc.).
To complicate things, the SDK is multiplatform, implying I'd need different ways to solve the problem depending on the platform (Windows, Linux, Mac OS, iOS, Android, ...) and compiler used (e.g., MSVC++ and g++).
Thank you.
Update
It seems I am VENDOR2 of this question:
Linking with multiple versions of a library
bstpierre's answer seems a viable solution, but I'm not sure it works or if it can be reproduced on OSes other than *nix.
765
In computer science, a static library or statically-linked library is a set of routines, external functions and variables which are resolved in a caller at compile-time and copied into a target application by a compiler, linker, or binder, producing an object file and a stand-alone executable.
By using dynamic linking, you can upgrade the routines in the shared libraries without relinking. Because this form of linking is the default, you need no additional options to turn it on. Static linking means that the code for all routines called by your program becomes part of the executable file.
A .o file inside a library might contain symbols (functions, variables etc.) that are not used by your program. At link time, a static library can have unresolved symbols in it, as long as you don't need the unresolved symbols, and you don't need any symbol that is in a .o file that contains an unresolved symbol.
I've had this problem many times with static libs, most recently with MSVCRT. With a single executable, the One Definition Rule gets in the way, as one commenter points out. There's really no way around this, that I can think of, short of patching binaries. And you'd have to do this "deeply" - catching all internal references that static library Y (zlib) makes to its own external-linkage objects.
In this case, I'd suggest using a dynamic library (DLL or SO). It will add a bit of deployment complexity. But it provides an executable "firewall", permitting global objects with the same name to reside in each binary without colliding. Even so, it can pose problems if both app and DLL have conflicting third-party dependencies. Still, probably the best option.
170
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
