Shared objects and c/c++ symbol malfunction

4 posts / 0 new

Last post

Wed, 2013-08-21 18:50

alfkil

Offline

Last seen: 3 months 6 days 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...?

Thu, 2013-08-22 12:47

salass00

Offline

Last seen: 6 months 2 weeks ago

Joined: 2011-02-03 11:27

Probably the header files are

Probably the header files are missing:

#ifdef __cplusplus
extern "C" {
#endif
 
...
 
#ifdef __cplusplus
}
#endif

around the function prototypes.

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

extern "C" {
#include <...>
}

Fri, 2013-08-30 16:24

(Reply to #2) #3

alfkil

Offline

Last seen: 3 months 6 days 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.

Wed, 2013-10-30 23:26

(Reply to #3) #4

ssolie

Offline

Last seen: 11 years 4 weeks 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.

Search form

User login