Thanks! I had a similar change in mind. I dont think we need to create a
separate NN_LIB_VERSION variable though.
On Thu, Jan 4, 2018 at 12:24 AM Boszormenyi Zoltan <zboszor@xxxxx> wrote:
Apparently, it's not just symlinks.
Yocto uses some smart heuristics based on the libsomething.so files
and if a subpackage only contains a library plus its runtime symlinks,
the subpackage is created like this:
libsomething<major>_<pkgversion>-<release>_<arch>.ipk
i.e. libasound2_1.1.2-r0.0_i686.ipk for the alsa-lib library.
But it isn't so in the nanomsg case.
Yocto doesn't find the major library version, only the full
library version and creates the package like this:
libnanomsg5.1.0_1.1.2-r1.0_i686.ipk
or
libnanomsg5.0.0_1.0.0-r1.0_i686.ipk
Also, applications linked with nanomsg indicate full library
version for libnanomsg.so in the ldd output. E.g., here is
the output from our POS system, comparing nanomsg and pciutils,
where the latter uses autoconf / automake / libtool to create
the library:
[root@pos ~]# ldd /usr/libexec/pos/pos | egrep '(libpci|libnano)'
libpci.so.3 => /usr/lib/libpci.so.3 (0xb729f000)
libnanomsg.so.5.1.0 => /usr/lib/libnanomsg.so.5.1.0 (0xb6f07000)
It is so despite I have tweaked the nanomsg 1.1.2 recipe to
forcibly create the runtime symlink with the major version:
[root@pos ~]# opkg files libnanomsg5.1.0
Package libnanomsg5.1.0 (1:1.1.2-r1.0) is installed on root and has the
following files:
/usr/lib/libnanomsg.so.5.1.0
/usr/lib/libnanomsg.so.5
The library subpackage of pciutils looks similar:
[root@pos ~]# opkg files libpci3
Package libpci3 (3.5.1-r0.0) is installed on root and has the following
files:
/usr/lib/libpci.so.3.5.1
/usr/lib/libpci.so.3
Finally this link answered the above:
https://unix.stackexchange.com/questions/58846/viewing-linux-library-executable-version-info
From my own Fedora 27 system, with nanomsg built for 32-bit:
[zozo@s002 ~]$ readelf -d /usr/lib/libpci.so.3.5.5 | grep SONAME
0x0000000e (SONAME) Library soname: [libpci.so.3]
[zozo@s002 ~]$ readelf -d /usr/lib/libnanomsg.so.5.1.0 | grep SONAME
0x0000000e (SONAME) Library soname:
[libnanomsg.so.5.1.0]
The fact that nanomsg encodes the full file name instead of only
the major library version creates a hard upgrade path. Everything
that's linked to nanomsg must be rebuilt and shipped with the
upgraded nanomsg package. This changes fixed this problem:
https://github.com/nanomsg/nanomsg/pull/939
Best regards,
Zoltán Böszörményi
2018-01-02 20:01 keltezéssel, Garrett D'Amore írta:
Thanks for noticing. I will see if I can convince CMake to ship theright major symbolic
links — you’re right that this should be created or updated by default.Probably I should bake it
NNG is still pre-release, and lacks any form of ABI versioning.
at 0.0.0 or somesuch.dmarc-noreply@xxxxxxxxxxxxx
I’ll need to investigate the use of the unversioned symbolic links.
On Tue, Jan 2, 2018 at 3:27 AM Boszormenyi Zoltan <
<mailto:dmarc-noreply@xxxxxxxxxxxxx>> wrote:library
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
name that NNanoMsg happens to dlopen() is not stable and I thinkthis is
the reason why it ships its own libnanomsg.so copy.for us.
Which, in turn, caused the situation of conflicting library symbols
The C code is directly linked with nanomsg and NNanoMsg dlopen()s adifferent
copy of the library from somewhere else.installed
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
library is simply libnng.so without any version in the name andobviously
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
