Comments (13)
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.
from opensm.
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).
from opensm.
I have patch which fixes it in my environment. Would you try it in yours to be sure before I push it ? Thanks.
from opensm.
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.
from opensm.
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 ?
from opensm.
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.
from opensm.
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.
from opensm.
Take your time. There is no hurry. 😄
from opensm.
Just sent patch to "Eliminate circular dependencies in shared libraries". Please test in your environment and see if this fixes the issue. Thanks again.
from opensm.
Yes. It builds and makes lintian happy.
from opensm.
Just pushed this patch
from opensm.
Thanks. Please don't forget to bump the soname in the next release (for the moved symbols).
from opensm.
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.
from opensm.
Related Issues (15)
- Question about the release .tar.gz files HOT 2
- opensm has errors from man HOT 3
- non-POSIX variable name in Makefile.am
- Remove structure packing where not needed HOT 4
- libopensm version HOT 5
- OpenSM: Add information about limitations HOT 4
- opensm high load issue
- Opensm 3.3.21 Crash on debian systems
- partitions.conf uses magic values for rate and mtu which are not documented HOT 1
- subnet_prefix not honored with recent kernels HOT 6
- New release HOT 2
- git tags are not consistent HOT 2
- libosmcomp.so calls exit HOT 6
- Please provide systemd service files HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from opensm.