f



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

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

0
victorcionca
4/25/2007 1:14:08 PM
comp.os.linux.development.apps 5216 articles. 1 followers. Post Follow

4 Replies
991 Views

Similar Articles

[PageSpeed] 10

victorcionca@gmail.com writes:

> 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.

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

> The mpeg2 libraries are all linked and it should work

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.
0
Paul
4/26/2007 12:06:24 AM
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

0
victorcionca
4/26/2007 10:21:08 AM
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

0
victorcionca
4/26/2007 10:32:53 AM
victorcionca@gmail.com writes:

> No, I did link them into the component, that's what I meant in the
> original post.

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.

> 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.

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.

> 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

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.
0
Paul
4/26/2007 4:37:25 PM
Reply: