Thanks for noticing. I will see if I can convince CMake to ship the right
major symbolic links — you’re right that this should be created or updated
by default.
NNG is still pre-release, and lacks any form of ABI versioning. Probably I
should bake it at 0.0.0 or somesuch.
I’ll need to investigate the use of the unversioned symbolic links.
On Tue, Jan 2, 2018 at 3:27 AM Boszormenyi Zoltan <
dmarc-noreply@xxxxxxxxxxxxx> wrote:
Hi,
we are using a hybrid Mono executable and both the C parts and
the Mono parts are currently using nanomsg, the Mono part is using
NNanoMsg obviously, which happens to ship its own outdated version
of libnanomsg.so.
The core of the problem is that nanomsg (1.1.2) only ships these:
/usr/lib*/libnanomsg.so.5.1.0
/usr/lib*/libnanomsg.so -> libnanomsg.so.5.1.0
There is no symlink with only the major library version and the
libnanomsg.so symlink, when packaged, only occurs in the -dev(el)
subpackage.
BTW, nanomsg 1.0.0 was doing the same, with libnanomsg.so.5.0.0
This creates the situation in deployment (i.e. no SDK) that the library
name that NNanoMsg happens to dlopen() is not stable and I think this is
the reason why it ships its own libnanomsg.so copy.
Which, in turn, caused the situation of conflicting library symbols for us.
The C code is directly linked with nanomsg and NNanoMsg dlopen()s a
different
copy of the library from somewhere else.
To fix this, nanomsg should ship the two symlinks this way:
/usr/lib*/libnanomsg.so.5.1.0
/usr/lib*/libnanomsg.so.5 -> libnanomsg.so.5.1.0
/usr/lib*/libnanomsg.so -> libnanomsg.so.5
I also have an experimental fork of NNanoMsg at:
https://github.com/zboszor/NNanomsg/commits/fix-link-order
On the same note, I just build NNG 0.2.0 and the name of the installed
library is simply libnng.so without any version in the name and obviously
there are no major version symlink or SDK symlink.
Some packagers, like Yocto's Bitbake framework, would complain loudly
about this by default, i.e. a file name that should be in the SDK
subpackage would end up in the library package.
Best regards,
Zoltán Böszörményi
