27

I can't be the only one to run into this.

I have a C++ application that needs to link with one third-party and another static library set in an SDK. The SDK has, for some hideously frustrating reason, recompiled a subset of that same third-party library into their own (renamed) lib, although the symbols themselves are named the same and they are not encapsulated within a namespace. My application itself depends upon the same third-party library.

I've considered a few options, but maybe I'm missing something and hopefully a fresh look will help me out. Perhaps I'm close and someone will know the next step for one of these . I'll enumerate what I've tried and the shortcomings of each solution so far:

  1. Link with both. I get about 2500 lines of symbol redefinition / size change warnings and errors. This is when I first found that they defined the same symbols. I'm trying to recompile OpenSSL with g++ and drop it into a namespace at the moment...see edit below...

  2. Link with the SDK only. I get undefined symbols that my own code depends upon - this is when I found that their recompile of the third party lib is a subset, or at least was configured with one module disabled.

  3. Link with the third party lib only. I have a couple of undefined symbols reported by the SDK - one of them is actually a #define in a header file within the third party lib, so all references in the third party lib resolve to the definition, but references outside there do not. I moved that into the c file, which resolves that, however I still have two unresolved functions I can't find anywhere. This is the closest I've gotten so far.

  4. Strip conflicting symbols from one lib and link in both. So far this hasn't worked. It could be a version issue between the lib statically linked in the SDK and the versions I've tried using of the third-party lib, but it looks like some functions were moved between symbols, so by removing a symbol, I inadvertently remove a function that I need elsewhere. There doesn't seem to be a perfect mapping between functions in symbols in the SDK vs functions in symbols in the third-party lib. Is it plausible to strip functions without having to manually adjust addresses?

I've been examining symbols in libs with:

nm -C --defined-only lib<name>.a

And extracting entire objects with:

ar -x lib<name>.a <objname>.o

Hopefully this will also help others who have had to link with third-party libs that conflict with one another. For the sake of specifics, the third-party lib is OpenSSL, and the SDK is Opsec - libcpopenssl.a is the offending lib in Opsec.

**EDIT- A late entry possible workaround may be to recompile OpenSSL with g++ and put the whole thing in a namespace, and then link both libs. I'm trying that now...more to come...

rutgersmike
  • 1,183
  • 9
  • 18
  • Can you leave *out* the opsec openssl derivative, and link your OpenSSL instead? It sounds like they included libcopopenssl.a in case you didn't have OpenSSL to link with. The symbols should wire up if they split out their OpenSSL derivative correctly. I.e. link everything else in their lib-set *except* that lib, and link OpenSSL in instead. – WhozCraig Nov 02 '12 at 17:08
  • That's what I tried in #3 above, essentially. I had to move a #define into a C file and recompile, and then I still had two undefined symbols. I can't find SSL_get_peer_dh or DH_dup anywhere. – rutgersmike Nov 02 '12 at 17:43
  • Couldn't you script with `nm` to grab they symbols from the *good* OpenSSL. Then strip the *bad* lib of this name list. If they have statically linked, then the internal references are already resolved. Or if not, use `-r` or `-Ur` to the linker. – artless noise Mar 28 '13 at 18:35

2 Answers2

3

A Google search indicate that SSL_get_peer_dh and DH_dup are really additions from libcpopenssl.a, and they don't exist in my copy of OpenSSL either. So you'll really have to link that library in. Mixing both libraries together (Approach 4 above) at binary level is unlikely to work -- OpenSSL is very picky about its ABI (they usually have .so files versioned down to the minor number) so you'd have to be very lucky to have an .so that's ABI-compatible to their .a file.

My suggestion is a variation of Approach 4, but at source level: you'll have link in the Opsec libcpopenssl.a, since it's a modified version of OpenSSL which include extra symbols (and possibly other modifications), and grab the extra functions you need from the OpenSSL sources and recompile those objects with libcpopenssl.a, so they can use the functions from the Opsec version. If you're only using a few OpenSSL functions which are not exported by libcpopenssl.a, this is quite doable.

Granted, that's still a cumbersome approach, but it's a guaranteed way to get symbol compatibility, provided of course that the Opsec SDK didn't make semantic changes to OpenSSL that will break the additional OpenSSL functions that you're pulling into your project.

(I'm new at StackOverflow so I don't know if this suggestion qualifies as a proper answer, but I don't have reputation points to post comments, anyway. I'll remove this if it's inappropriate.)

Hisham H M
  • 6,398
  • 1
  • 29
  • 30
  • I couldn't find much on those functions, thanks! I got tired of modding OpenSSL but that's sort of where I'm headed, I'm going to try to compile it for c++ and drop it into a namespace. I'll update when i have more info. – rutgersmike Nov 03 '12 at 22:08
1

If you're morbidly curious, 249 files were modified in the most recent version of OpenSSL to get it to compile. The most common issue by far was the abundance of C-style pointer casts, particularly with void*. Now I see "reinterpret_cast" in my dreams.

This didn't solve it alone though - it still needs to be placed into a namespace in its entirety, which means modifying all of the files again as well as my own internal references to it. I think I'm going to pass on this for now.

Thanks for the help everyone.

rutgersmike
  • 1,183
  • 9
  • 18