Closed bdrung closed 5 years ago
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.
Looking at the symbols:
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).
I have patch which fixes it in my environment. Would you try it in yours to be sure before I push it ? Thanks.
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.
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 ?
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.
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.
Take your time. There is no hurry. :smile:
Just sent patch to "Eliminate circular dependencies in shared libraries". Please test in your environment and see if this fixes the issue. Thanks again.
Yes. It builds and makes lintian happy.
Just pushed this patch
Thanks. Please don't forget to bump the soname in the next release (for the moved symbols).
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.
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.