search

linux-rdma / opensm

Other
66 stars 36 forks source link

Unresolved symbols in shared libraries #7

Closed bdrung closed 5 years ago

bdrung commented 5 years ago

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

bdrung commented 5 years ago

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

hnrose commented 5 years ago

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

bdrung commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

Take your time. There is no hurry. :smile:

hnrose commented 5 years ago

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 commented 5 years ago

Yes. It builds and makes lintian happy.

hnrose commented 5 years ago

Just pushed this patch

bdrung commented 5 years ago

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

hnrose commented 5 years ago

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.