Shared objects and c/c++ symbol malfunction

4 posts / 0 new
Last post
alfkil
alfkil's picture
Offline
Last seen: 2 years 7 months ago
Joined: 2011-05-10 22:02
Shared objects and c/c++ symbol malfunction

Ok, I am pretty sure this is a bug in the dynamic linker, but I'll post here anyway to see, if someone has a straightforward explanation of the phenomenon.

Short store: You take libjpeg.so (which is, apparently, a c only lib). You then create a c++ file referencing it, remembering to #include , so that the c symbols are recognized. You then create a shared object out of the c++ file you just created, remembering to use the -shared flag with c++. You then create a main c++ file referencing the newly created shared object in a way, that triggers its reference to libjpeg.so. Link it, and what do you get? All your jpeg symbols are 0!

If you reference jpeg in the main c++ file, there are no problems.

This problem seems to only occur when mixing c and c++ shared objects in a way, so the c objects are subordinate to the c++ objects. Solution??

See my full project here (just run "make" on it):
https://dl.dropboxusercontent.com/u/5482530/Code%20examples/jpeg_error.lha

EDIT: Ok, apparently this problem only arise with some shared objects. Tried:

libjpeg.so FAIL
libpng.so FAIL
libz.so WORKS
homemade.so WORKS

So something must be fishy with libjpeg.so and libpng.so. Objdump shows, that all the symbol names are preceded by a library version string, as contrary to libz... Could that be an issue...?

salass00
salass00's picture
Offline
Last seen: 1 year 1 month ago
Joined: 2011-02-03 11:27
Probably the header files are

Probably the header files are missing:

  1. #ifdef __cplusplus
  2. extern "C" {
  3. #endif
  4.  
  5. ...
  6.  
  7. #ifdef __cplusplus
  8. }
  9. #endif

around the function prototypes.

You can workaround it in your own code by adding it around the include statement like so:

  1. extern "C" {
  2. #include <...>
  3. }
alfkil
alfkil's picture
Offline
Last seen: 2 years 7 months ago
Joined: 2011-05-10 22:02
No, the extern "C" statement

No, the extern "C" statement doesn't change the outcome (it is present in the header file). Thomas Frieden explained the problem to me, and it has to do with versioned symbols. If I do objdumt -T libjpeg.so, I can see, that the symbols are prefixed with 'LIBJPEG_9.0'. The same for libpng. libz.so doesn't have those. The problem is in elf.library, and will hopefully be properly fixed at some point. Until then I have had to create my own libjpeg.so with no versioned symbols, that seems to have temporarily solved the problem.

ssolie
ssolie's picture
Offline
Last seen: 10 years 5 months ago
Joined: 2011-02-03 06:55
You are correct. A fix for

You are correct. A fix for elf.library is needed to avoid this problem completely.

Log in or register to post comments