Hello all,
I’m trying to analyze the problem behind https://bugzilla.novell.com/show_bug.cgi?id=475808
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:
/usr/lib64/libcapi20.so
/usr/lib64/capi/lib_capi_mod_fritzbox.so
/usr/lib64/capi/lib_capi_mod_rcapi.so
/usr/lib64/capi/lib_capi_mod_std.so
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 libcapi20.so, 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/lib_capi_mod_std.so: 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/libcapi20.so” shows:
0000000000004250 T processMessage
So it seems the three lib_capi_mod_ libraries don’t get properly linked to libcapi20.so. 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/Makefile.am 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 lib_capi_mod_std.la -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,lib_capi_mod_std.so.0 -o .libs/lib_capi_mod_std.so.0.0.0
I thought this should include libcapi20.so in order to resolve the reference to processMessage, so I tried adding a line
lib_capi_mod_std_la_LIBADD = libcapi20.la
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 lib_capi_mod_std.la -rpath /usr/lib64/capi lib_capi_mod_std_la-capi_mod_std.lo libcapi20.la
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/libcapi20.so -lc -ldl -m64 -Wl,-soname -Wl,lib_capi_mod_std.so.0 -o .libs/lib_capi_mod_std.so.0.0.0
But the problem persists. The error message “undefined symbol: processMessage” still appears, and “nm lib_capi_mod_std.so” still shows “U processMessage”.
What am I missing?