[SSSD] Libtool fails to find dependent libraries

Timo Aaltonen tjaalton at ubuntu.com
Tue May 14 19:20:31 UTC 2013


14.05.2013 20:57, Lukas Slebodnik kirjoitti:
> ehlo,
> 
> sorry for tl;dr
> 
> Two users hit the same compilation issue last week.
> https://lists.fedorahosted.org/pipermail/sssd-devel/2013-May/014906.html
> https://lists.fedorahosted.org/pipermail/sssd-devel/2013-May/014915.html
> The first user uses Ubuntu and the second user uses Mint.
> 
> The main problem is in linking process. There are undefined references to
> symbol. And linker writes hint, where the symbol is defined.
> /usr/bin/ld: note: '_talloc_zero_array@@TALLOC_2.0.2' is defined in DSO
> /usr/lib/i386-linux-gnu/libtalloc.so.2 so try adding it to the linker command line
> 
> It was very strange, because configure script did not fail and all dependencies
> were installed properly. I found out that problem is in libtool. Debian (and
> all derivatives) has patched version of libtool.
> http://patch-tracker.debian.org/patch/series/view/libtool/2.4.2-1.1/link_all_deplibs.patch
> They set link_all_deplibs to "no". Fedora has default value "unknown", which is
> treated like "yes".

>From the Debian patch:

## Do not link against deplibs.  This is not needed for shared libs
## on atleast ELF systems since those already know which libs they
## need themself.  This seems to break a few things and will be fixed
## in a better way in a future upstream version.

.. but nine years have gone by since the patch was added, and it's
unknown to me why a better solution hasn't found it upstream yet :)

Asked about this on IRC too, and overlinking was mentioned to have
several issues. An obvious one is performance on startup, a more serious
is if one of the lib deps changes soname of something it links against,
and you could load two versions to the memory at the same time.. "and
hilarity ensues"





More information about the sssd-devel mailing list