Problem with linking C shared library into C++ shared library

Problem with linking C shared library into C++ shared library

Post by victorcion » Thu, 26 Apr 2007 22:14:08


Hello!

A Corba Components server uses Components as shared libraries that are
loaded into the server at runtime. Everything is C++ but I wrote a
component which uses libmpeg2 for video decoding and displaying.

I use "extern C" to use the mpeg2 C code inside the C++ component. The
component shared library compiles and links ok, but when I try to load
it into the server I get a
"cannot load shared library; undefined symbol" error, for all symbols
from libmpeg2.

The mpeg2 libraries are all linked and it should work: I tried a
simple executable with mpeg2, the code using mpeg2 was the same as in
the component and it worked.

Any help, please?

Victor Cionca
 
 
 

Problem with linking C shared library into C++ shared library

Post by Paul Pluzh » Fri, 27 Apr 2007 09:06:24


XXXX@XXXXX.COM writes:


Guess: you neglected to link your "C++ component" with mpeg2 libs.


Maybe it should, but how do you expect mpeg2 libraries to get loaded?

Either your main exe must have them as direct dependencies (which
is unlikely), or your "component" has to link against them.

Use 'objdump -p component.so | grep NEEDED' to find out what you
linked against. I am guessing you will not see mpeg2 libs there.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

 
 
 

Problem with linking C shared library into C++ shared library

Post by victorcion » Fri, 27 Apr 2007 19:21:08

No, I did link them into the component, that's what I meant in the
original post.
Anyway, here is the objdump output. With the needed libmpeg2 :) Maybe
it will help a bit. I am guessing it somehow has to do with the fact
that I am trying to build a C++ shared library that links to a C
shared library and is loaded into a C++ app.



Dynamic Section:
NEEDED libmpeg2.so.0
NEEDED libmpeg2convert.so.0
NEEDED libXext.so.6
NEEDED libX11.so.6
NEEDED libStreaming_SinkComposition_SERVANT.so
NEEDED libmico2.3.12.so
NEEDED libssl.so.0.9.8
NEEDED libcrypto.so.0.9.8
NEEDED libdl.so.2
NEEDED libpthread.so.0
NEEDED libstdc++.so.6
NEEDED libm.so.6
NEEDED libgcc_s.so.1
NEEDED libc.so.6
INIT 0x5f50
FINI 0x85e0
HASH 0xd4
STRTAB 0x1b14
SYMTAB 0x964
STRSZ 0x2efe
SYMENT 0x10
PLTGOT 0xa378
PLTRELSZ 0x138
PLTREL 0x11
JMPREL 0x5e18
REL 0x4cc8
RELSZ 0x1150
RELENT 0x8
TEXTREL 0x0
VERNEED 0x4c48
VERNEEDNUM 0x3
VERSYM 0x4a12
RELCOUNT 0x46

Version References:
required from libgcc_s.so.1:
0x0b792650 0x00 06 GCC_3.0
required from libc.so.6:
0x0d696910 0x00 05 GLIBC_2.0
0x09691f73 0x00 03 GLIBC_2.1.3
required from libstdc++.so.6:
0x056bafd3 0x00 04 CXXABI_1.3
0x08922974 0x00 02 GLIBCXX_3.4
 
 
 

Problem with linking C shared library into C++ shared library

Post by victorcion » Fri, 27 Apr 2007 19:32:53

Here is the command used to generate the component shared library:

g++ -shared -o libStreaming_SinkComposition.so
Streaming_SinkComposition_BUSINESS.o Streaming_SinkComposition.o
mpeg2dec.c component_valuetypes.o -lmpeg2 -lmpeg2convert -Llibvo -lvo -
L/usr/X11R6/lib -lXext -lX11 -L../Streaming_SinkComposition_SERVANT -
lStreaming_SinkComposition_SERVANT -rdynamic -L/usr/local/lib -
lmico2.3.12 -lssl -lcrypto -ldl -lm -lpthread
 
 
 

Problem with linking C shared library into C++ shared library

Post by Paul Pluzh » Sat, 28 Apr 2007 01:37:25


XXXX@XXXXX.COM writes:


Since you are also allegedly using 'extern "C"', everything is
correct then. But since you can't load the "component", you must
be doing something wrong.


Your guess is likely wrong, and your problem is elsewhere.
There are absolutely no issues doing the above (provided correct
'extern "C"' is used).

Begin by verifying that libmpeg2* loaded at runtime in fact do
define the symbols that the loader says are missing.

env LD_DEBUG=files /path/to/exe

Above will tell which libmpeg2*.so.0 are loaded (they may not be
the ones you expected).

objdump -T /path/to/libmpeg2*.so.0 | grep insert-unresolved-symbol-name-here

The symbols you desire may not be exported, or they may be hidden.
Posting the error message you get from dlerror() may provide clues as well.

Finally, running with LD_DEBUG=symbols,bindings should give you a lot more info.


The '-rdynamic' above is useless (but harmless).
It is better to use '-pthread' at compile and link, than to link with -lpthread.
Otherwise, I do not see anything wrong with the link line.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.