Unresolved symbols in shared libraries

[bdrung]

The shared objects have some unresolved symbols which the program which links against it must resolve. This isn't a good idea because when you introduce new dependencies the package previously linked against the old version will break because it doesn't know about the new dependency. Maybe you could link against all needed libraries so programs must not link against libraries which it doesn't need to use.

dpkg-shlibdeps: warning: symbol osm_log_v2 used by debian/libosmvendor4/usr/lib/x86_64-linux-gnu/libosmvendor.so.4.0.3 found in none of the libraries
dpkg-shlibdeps: warning: symbol osm_mad_pool_get used by debian/libosmvendor4/usr/lib/x86_64-linux-gnu/libosmvendor.so.4.0.3 found in none of the libraries
dpkg-shlibdeps: warning: symbol osm_mad_pool_put used by debian/libosmvendor4/usr/lib/x86_64-linux-gnu/libosmvendor.so.4.0.3 found in none of the libraries
dpkg-shlibdeps: warning: symbol osm_log used by debian/libosmvendor4/usr/lib/x86_64-linux-gnu/libosmvendor.so.4.0.3 found in none of the libraries
dpkg-shlibdeps: warning: symbol osm_dump_smp_dr_path used by debian/libosmvendor4/usr/lib/x86_64-linux-gnu/libosmvendor.so.4.0.3 found in none of the libraries
dpkg-shlibdeps: warning: symbol cl_atomic_spinlock used by debian/libopensm8/usr/lib/x86_64-linux-gnu/libopensm.so.8.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol osm_vendor_get used by debian/libopensm8/usr/lib/x86_64-linux-gnu/libopensm.so.8.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol cl_spinlock_init used by debian/libopensm8/usr/lib/x86_64-linux-gnu/libopensm.so.8.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol cl_spinlock_acquire used by debian/libopensm8/usr/lib/x86_64-linux-gnu/libopensm.so.8.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol cl_get_time_stamp used by debian/libopensm8/usr/lib/x86_64-linux-gnu/libopensm.so.8.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol cl_spinlock_release used by debian/libopensm8/usr/lib/x86_64-linux-gnu/libopensm.so.8.0.0 found in none of the libraries
dpkg-shlibdeps: warning: symbol osm_vendor_put used by debian/libopensm8/usr/lib/x86_64-linux-gnu/libopensm.so.8.0.0 found in none of the libraries

[hnrose]

All those symbols are in the various internal OpenSM libraries (libopensm, libosmcomp (complib), libosmvendor). I don't know what dpkg-shlibdeps does but either dependency is missing or it might be due to circular dependency in these libraries.

[bdrung]

Looking at the symbols:

• libosmvendor uses symbols from libopensm
• libopensm uses symbols from libosmcomp and libosmvendor

Looking at the libraries, only libosmvendor is linked against libosmcomp:

# ldd /usr/lib/x86_64-linux-gnu/libopensm.so.8.0.0
	linux-vdso.so.1 (0x00007fffd856d000)
	libibumad.so.3 => /usr/lib/x86_64-linux-gnu/libibumad.so.3 (0x00007fa7cdcfb000)
	libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007fa7cdaf1000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa7cdaec000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa7cdacb000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa7cd90a000)
	libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007fa7cd8f1000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fa7cdd24000)
# ldd /usr/lib/x86_64-linux-gnu/libosmcomp.so.4.0.0
	linux-vdso.so.1 (0x00007fff12a9d000)
	libibumad.so.3 => /usr/lib/x86_64-linux-gnu/libibumad.so.3 (0x00007f3aa3863000)
	libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f3aa3659000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3aa3654000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3aa3633000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3aa3472000)
	libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f3aa3459000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f3aa3887000)
# ldd /usr/lib/x86_64-linux-gnu/libosmvendor.so.4.0.3
	linux-vdso.so.1 (0x00007ffc477f6000)
	libosmcomp.so.4 => /usr/lib/x86_64-linux-gnu/libosmcomp.so.4 (0x00007f677132e000)
	libibumad.so.3 => /usr/lib/x86_64-linux-gnu/libibumad.so.3 (0x00007f6771322000)
	libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f6771118000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6771113000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f67710f2000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6770f31000)
	libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f6770f16000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f6771351000)

That explains why dpkg-shlibdeps complains about it. So libopensm should link against libosmcomp and libosmvendor. Also libosmvendor should link against libopensm (if circular dependencies are allowed).

[hnrose]

I have patch which fixes it in my environment. Would you try it in yours to be sure before I push it ? Thanks.

[bdrung]

I tried your patch and it fails to build:

make[1]: Entering directory '/<<PKGBUILDDIR>>'
Making all in complib
make[2]: Entering directory '/<<PKGBUILDDIR>>/complib'
[...]
libtool: link: [...] -o .libs/libosmcomp.so.4.0.0
[...]
make[2]: Leaving directory '/<<PKGBUILDDIR>>/complib'
Making all in libvendor
make[2]: Entering directory '/<<PKGBUILDDIR>>/libvendor'
Making all in .
make[3]: Entering directory '/<<PKGBUILDDIR>>/libvendor'
[...]
/bin/bash ../libtool  --tag=CC   --mode=link gcc -Wall -Wwrite-strings -g -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -version-info 4:3:0 -export-dynamic -Wl,--version-script=./libosmvendor.map -Wl,-z,relro -Wl,-z,now -o libosmvendor.la -rpath /usr/lib/x86_64-linux-gnu libosmvendor_la-osm_vendor_ibumad.lo libosmvendor_la-osm_vendor_ibumad_sa.lo -L../complib -losmcomp -L../opensm -lopensm -libumad -lwrap -ldl -lpthread 
libtool: link: gcc -shared  -fPIC -DPIC  .libs/libosmvendor_la-osm_vendor_ibumad.o .libs/libosmvendor_la-osm_vendor_ibumad_sa.o   -Wl,-rpath -Wl,/<<PKGBUILDDIR>>/complib/.libs -L../complib /<<PKGBUILDDIR>>/complib/.libs/libosmcomp.so -L../opensm -lopensm -libumad -lwrap -ldl -lpthread  -g -g -O2 -fstack-protector-strong -Wl,--version-script=./libosmvendor.map -Wl,-z -Wl,relro -Wl,-z -Wl,now   -Wl,-soname -Wl,libosmvendor.so.4 -o .libs/libosmvendor.so.4.0.3
/usr/bin/ld: cannot find -lopensm

The problem is the circular dependency. Without having built the opensm library, you cannot link libvendor against it.

[hnrose]

Need to think about this more but I think the libraries need to be restructured so as not to have circular dependency or do you see another way around this ?

[bdrung]

Breaking the circular dependency is a good idea. If you always need both, why not merge them? Otherwise one library should be upper-level and the other one lower-level.

[hnrose]

They are separate libraries based on purpose: libvendor is interface to IB device, complib is OS portability layer, and libopensm is generic to opensm. complib is lowest level library and with proposed restructuring libopensm would be next, with libvendor the upper most library layer. It will take me a little time to do this. Stay tuned.

[bdrung]

Take your time. There is no hurry. 😄

[hnrose]

Just sent patch to "Eliminate circular dependencies in shared libraries". Please test in your environment and see if this fixes the issue. Thanks again.

[bdrung]

Yes. It builds and makes lintian happy.

[hnrose]

Just pushed this patch

[bdrung]

Thanks. Please don't forget to bump the soname in the next release (for the moved symbols).

[hnrose]

I'll do my best; it's part of the OpenSM release process to check the library differences from previous release and bump soname accordingly. Thanks.