views:

729

answers:

3

My (C++, cross-platform) app is heavily using Boost libraries (say version 1.x), and I want to also link against a 3rd-party (vendor)'s SDK (no source), itself using Boost (but version 1.y).

So, we both link dynamically against our own version of Boost DLLs, CRT being identical. Consequently, at run-time my app would have to load both DLL of Boost 1.x & 1.y.

What are the potential issues & gotchas associated?

I can't change vendor's SDK, but I can change my app. Maybe I should try to link statically against my Boost 1.x?

PS: Name of Boost's DLL include their version, so no name collision, both are identifiable. Not the usual DLL-hell.

A: 

If you write a function foo, and export it from F.dll, and another function foo exported from G.dll, would you expect problems?

When AF.exe is linked, the linker is told: put some code in there that loads the address of function foo from F.dll. Now BG.dll is linked to retrieve the foo address from G.dll. I still see no problem.

Now replace AF.exe with your app, BG.dll with your vendor's app, F.dll with your boost version, G.dll with the vendor's boost version.

Concluding: I see no problems if the dll names are different.

xtofl
+2  A: 

As far as using the DLLs for different versions there should be no problem. At least not on Windows.

This is true if the SDK is using boost internally. If the SDK uses boost constructs in its interface, for example: it has a function that returns a boost::optional, then having multiple versions can cause problems. It could still work fine, dependent on the changes between the versions, but that will definitely be a risk. I don't know of any good solution in that case. This is also true if you include a SDK header file that includes a boost header file.

Dani van der Meer
+1  A: 

This is a big problem. Do a search on DLL hell.

Basically the DLL (or shared libs in Linux) are loaded but not all the names are resolved at load time. What happens is a lazy evaluation, so the names are evaluated on first use. The problem is that if 2 dll have the same name then the location where the name is resolved to depends on the what order the DLL are searched in (which depends on load order).

If you statically link then you will not have problems with method calls as yours will all be resolved at compile time and the third party will be resolved at runtime from the DLL. But what about structures that are created by version-1 boost. If you then pass these to the third party library that then passes it to the version-x boost. Are the structures layed out in the same way?

This is a very tricky area and when problems occur very hard to de-bug. So try and use the same version.

Martin York