[SSSD] Libtool fails to find dependent libraries

Jakub Hrozek jhrozek at redhat.com
Wed May 15 09:09:35 UTC 2013


On Tue, May 14, 2013 at 07:57:25PM +0200, Lukas Slebodnik wrote:
> 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". Simple solution for users was to build sssd 1.10-beta from
> tarball and do not run autoreconf. Because all important files in tarball
> was generated on fedora.
> 
> Example:
> sss_userdel -> libsss_util.la  -> libsss_child.la
>                                -> libsss_crypt.la
>                                -> libsss_debug.la
>                                   ^^^^^^^^^
>           Those three dependencies are not propagated to the top (sss_userdel)
>           if link_all_deplibs is "no". Only direct dependencies from
>           libsss_util.la are used to link file sss_userdel.
> 
> This issue was introduced in commit 96453f402831275a39d5fb89c33c9776e148d03f
> "BUILD: Build shared components as an internal shared library"
> 
> It was not problem with static libraries, because everything from libraries
> libsss_{child,crypt,debug} was linked to libsss_util.a
> 
> 
> I was able to reproduce this bug with debian and my first solution was to patch
> generated ./libtool
> sed -i -e 's/^link_all_deplibs=.*$/link_all_deplibs=yes/' ./libtool
> But this was ugly hack, because you have to call configure and then patch
> generated libtool. I realized, that:
>    libtool (is generated by)
>             -> config.status(with ltmain.sh)
>                             (generated by)
>                              -> configure (generated from)
>                                            ->configure.ac
> 
> Macro AC_PROG_LIBTOOL is responsible for initialization of variable
> link_all_deplibs (and also other things)
> Macro AC_PROG_LIBTOOL expands to 7160 lines of shell script
> (aproximately 30% size of "configure")
> 
> Possible solutions:
>    --revert patch with internal shared library (I don't like it)

No, I see value in having the libraries as private shared
objects. The amount of disk space saved was tremendous and also this way
you make sure all the objects link to the same (shared) instance of
code.

>    --override value of variable link_all_deplibs in configure.ac
>       (after macro AC_PROG_LIBTOOL). I am not sure if it is portable
>       solution.

This would be a quick fix, but I'm concerned if this would break packaging
policies of other distributions and expectations they have on behaviour of
the projects in general. They'd assume all the projects built using their
toolchain to behave as per their distribution linker setting and we'd be
deliberately changing this expectation.

>    --update dependencies in Makefile.am, Every target which require
>       libsss_util.la will also directly require libsss_{child,crypt,debug}.
>       (lot of useless changes)

I suspect that in reality, most changes would amount to adding
libsss_debug.so directly, libsss_child is mostly used by back ends,
libsss_crypt by back ends and the obfuscation tools (IIRC). While ugly,
this seems like the most portable solution to me.

But I'm not a libtool expert, far from it. Stephen, I think you know
libtool the best in the team, do you have an opinion here?



More information about the sssd-devel mailing list