shared library interdependency problem

Hello all,

I’m trying to analyze the problem behind
That bug has gone unhandled for several years because it is associated with the ISDN subsystem and nobody feels competent for ISDN anymore.
The actual problem hasn’t much to do with ISDN however. It’s really a problem with correctly building interdependent shared libraries. Here’s what I found out so far:

The package capi4linux-2010.11.8-2.4.x86_64, built with others from source package i4l-base-2010.11.8-2.4.src.rpm, contains these four shared libraries:
The first one is loaded by applications wishing to use CAPI. The other three are plugin modules that will be loaded by the first one via dlopen(). So far, so good.

Now the plugin modules need to access certain functions of the master module, most notably processMessage(). This is where the problem starts. With some (but not all) CAPI applications, trying to load one of the plugin modules results in an error message:
symbol lookup error: /usr/lib64/capi/ undefined symbol: processMessage
killing the application.

“nm -u /usr/lib64/capi/lib_capi_mod_*.so” shows, for all three files:

U processMessage

while “nm /usr/lib64/” shows:

0000000000004250 T processMessage

So it seems the three lib_capi_mod_ libraries don’t get properly linked to But I’m at a loss how to fix that.

The package i4l-base-2010.11.8-2.4.src.rpm makes use of autoconf and libtool for building. The part that builds the shared libraries above is controlled by a file isdn4k-utils/capi20/ which contains these lines:

lib_capi_mod_std_la_SOURCES = capi_mod_std.c
lib_capi_mod_std_la_CFLAGS = -fno-strict-aliasing
lib_capi_mod_std_la_LDFLAGS = -shared

resulting in this link command:

/bin/sh ./libtool --tag=CC --mode=link gcc -fno-strict-aliasing -O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -shared -o -rpath /usr/lib64/capi lib_capi_mod_std_la-capi_mod_std.lo
libtool: link: gcc -shared .libs/lib_capi_mod_std_la-capi_mod_std.o -m64 -Wl,-soname -Wl, -o .libs/

I thought this should include in order to resolve the reference to processMessage, so I tried adding a line

lib_capi_mod_std_la_LIBADD =

which did succeed in modifying the link command as intended, to:

/bin/sh ./libtool --tag=CC --mode=link gcc -fno-strict-aliasing -O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -shared -o -rpath /usr/lib64/capi lib_capi_mod_std_la-capi_mod_std.lo
libtool: link: gcc -shared .libs/lib_capi_mod_std_la-capi_mod_std.o -Wl,-rpath -Wl,/home/ts/src/rpm/BUILD/isdn4k-utils/capi20/.libs ./.libs/ -lc -ldl -m64 -Wl,-soname -Wl, -o .libs/

But the problem persists. The error message “undefined symbol: processMessage” still appears, and “nm” still shows “U processMessage”.

What am I missing?

Use “readelf -d <libpath>” to check if the plugins are really linked to the main library.

And I would, in this order:
Remove the .la files
Try to avoid the use “-lc”

Thank you! That hint was exactly what I needed.

The readelf command showed me that

  • the original plugin libs were indeed not linked to the main library,
  • those built with the modification to I described in my previous posting were,
  • but still, those I was testing against were not!

Looks like I had somehow botched the reinstallation of the libraries after rebuilding them with that modification.
After installing them again from my latest build, the error message is gone and the CAPI application works fine.

Thanks again,