Created attachment 8344 [details] add realname while building libldb This issue got reported at the openSUSE bug tracking system at https://bugzilla.novell.com/show_bug.cgi?id=769155 Jan added a patch available at https://bugzilla.novell.com/show_bug.cgi?id=769155#c9 The attached patch has one negative side effect: [ 80s] * installing bin/default/libpyldb-util.so as /home/abuild/rpmbuild/BUILDROOT/ldb-1.1.14-0.x86_64/usr/lib64/libldb-1.1.14.so [ 80s] * installing bin/default/libldb.so as /home/abuild/rpmbuild/BUILDROOT/ldb-1.1.14-0.x86_64/usr/lib64/libldb.so.1.1.14
Without the proposed patch the install log part shows: [ 32s] * installing bin/default/libpyldb-util.so as /home/abuild/rpmbuild/BUILDROOT/ldb-1.1.14-0.x86_64/usr/lib64/libpyldb-util.so.1.1.14 [ 32s] * symlink /home/abuild/rpmbuild/BUILDROOT/ldb-1.1.14-0.x86_64/usr/lib64/libpyldb-util.so.1 (-> libpyldb-util.so.1.1.14) [ 32s] * symlink /home/abuild/rpmbuild/BUILDROOT/ldb-1.1.14-0.x86_64/usr/lib64/libpyldb-util.so (-> libpyldb-util.so.1.1.14) [ 32s] * installing bin/default/libldb.so as /home/abuild/rpmbuild/BUILDROOT/ldb-1.1.14-0.x86_64/usr/lib64/libldb.so.1.1.14 [ 32s] * symlink /home/abuild/rpmbuild/BUILDROOT/ldb-1.1.14-0.x86_64/usr/lib64/libldb.so.1 (-> libldb.so.1.1.14) [ 32s] * symlink /home/abuild/rpmbuild/BUILDROOT/ldb-1.1.14-0.x86_64/usr/lib64/libldb.so (-> libldb.so.1.1.14)
What does this try to solve? ./configure --prefix=/opt/ldb && make && make install produces this for me: root@ub1204-161:/opt/ldb/lib# ls -la total 284 drwxr-xr-x 5 root root 4096 Dec 12 13:01 . drwxr-xr-x 7 root root 4096 Dec 12 13:01 .. drwxr-xr-x 2 root root 4096 Dec 12 13:01 ldb lrwxrwxrwx 1 root root 16 Dec 12 13:01 libldb.so -> libldb.so.1.1.14 lrwxrwxrwx 1 root root 16 Dec 12 13:01 libldb.so.1 -> libldb.so.1.1.14 -rwxr-xr-x 1 root root 250929 Dec 12 13:00 libldb.so.1.1.14 lrwxrwxrwx 1 root root 23 Dec 12 13:01 libpyldb-util.so -> libpyldb-util.so.1.1.14 lrwxrwxrwx 1 root root 23 Dec 12 13:01 libpyldb-util.so.1 -> libpyldb-util.so.1.1.14 -rwxr-xr-x 1 root root 13259 Dec 12 13:00 libpyldb-util.so.1.1.14 drwxr-xr-x 2 root root 4096 Dec 12 13:00 pkgconfig drwxr-xr-x 3 root root 4096 Dec 12 13:00 python2.7 root@ub1204-161:/opt/ldb/lib# readelf -d libldb.so.1.1.14| grep soname 0x000000000000000e (SONAME) Library soname: [libldb.so.1]
I'd propose to fix this as invalid.
You have to either add symbol version maps (gcc -Wl,--version-script) to libldb.so, or you have to change the SONAME for every API change (for example, by using -release). Not doing so means upgrading LDB does not trigger automatic rebuilds for LDB modules in other packages, since in openSUSE Factory, we generally rely only on SONAME and symbol versions.
(In reply to comment #4) > You have to either add symbol version maps (gcc -Wl,--version-script) to > libldb.so, or you have to change the SONAME for every API change (for example, > by using -release). > Not doing so means upgrading LDB does not trigger automatic rebuilds for LDB > modules in other packages, since in openSUSE Factory, we generally rely only on > SONAME and symbol versions. We use symbol versioning see bin/default/ldb.vscript in the build directory. If modules doesn't depend on a specific version they might not want to use LDB_MODULE_CHECK_VERSION(). As long as modules don't use ldb_private.h and only ldb_module.h, they should be ok. As long as we only add new functions there's no need to change the soname.
(In reply to comment #5) > (In reply to comment #4) > > You have to either add symbol version maps (gcc -Wl,--version-script) to > > libldb.so, or you have to change the SONAME for every API change (for example, > > by using -release). > > Not doing so means upgrading LDB does not trigger automatic rebuilds for LDB > > modules in other packages, since in openSUSE Factory, we generally rely only on > > SONAME and symbol versions. > > We use symbol versioning see bin/default/ldb.vscript in the build directory. > > If modules doesn't depend on a specific version they might not want to > use LDB_MODULE_CHECK_VERSION(). As long as modules don't use > ldb_private.h and only ldb_module.h, they should be ok. > > As long as we only add new functions there's no need to change the soname. I have told as much to the other SSSD developers, however they didn't feel comfortable because upstream hasn't committed to not break the modules API/ABI so far. If the samba team can commit to that I have a oneliner patch to 'fix' this problem in SSSD