Bug 9495 - sssd fails to start due to relying on particular version of unversioned ldb
sssd fails to start due to relying on particular version of unversioned ldb
Status: NEW
Product: Samba 4.0
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB
4.0.0
All All
: P5 normal
: ---
Assigned To: Andrew Bartlett
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-12 10:50 UTC by Lars Müller
Modified: 2012-12-12 17:23 UTC (History)
2 users (show)

See Also:


Attachments
add realname while building libldb (574 bytes, patch)
2012-12-12 10:50 UTC, Lars Müller
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lars Müller 2012-12-12 10:50:54 UTC
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
Comment 1 Lars Müller 2012-12-12 13:05:33 UTC
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)
Comment 2 Stefan Metzmacher 2012-12-12 13:10:49 UTC
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]
Comment 3 Stefan Metzmacher 2012-12-12 13:21:04 UTC
I'd propose to fix this as invalid.
Comment 4 Jan Engelhardt 2012-12-12 16:04:27 UTC
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.
Comment 5 Stefan Metzmacher 2012-12-12 16:23:37 UTC
(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.
Comment 6 Simo Sorce 2012-12-12 17:23:43 UTC
(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