[SSSD] Libtool fails to find dependent libraries

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


On Wed, May 15, 2013 at 05:23:25AM -0400, Stephen Gallagher wrote:
> 
> 
> On May 15, 2013, at 5:09 AM, Jakub Hrozek <jhrozek at redhat.com> wrote:
> 
> > 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.
> > 
> 
> Please don't revert this. As Jakub says, it saved about 55% of the disk space, which was a big deal for embedded platforms.
> 
> 
> >>   --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.
> 
> Yeah, I agree. If distributions have set this explicitly, I assume they have their reasons. While I *suspect* that the reason in this case is just to ensure that all linkages are clearly visible, it would be disingenuous to alter that solely on our own initiative.
> 
> 
> > 
> >>   --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?
> 
> 
> I wouldn't call myself an expert on libtool either, but I'm inclined to
> agree that this is probably our least disruptive change. My recommendation
> would be to change all places in the Makefile.am that reference
> libsss_util.la to a variable substitution containing the complete set
> of dependencies and then adding a comment around the variable definition
> explaining the situation in detail (so we can reference it in the future
> if we start causing similar problems in other linkages).

I don't think we need to have the complete set everywhere (no need to
link against libsss_child.so in the tools for example), but in general
this makes sense.

Lukas, can you file a ticket please since you troubleshooted the issue?



More information about the sssd-devel mailing list