[SSSD] Libtool fails to find dependent libraries

Lukas Slebodnik lslebodn at redhat.com
Wed May 15 12:02:18 UTC 2013


On (15/05/13 11:45), Jakub Hrozek wrote:
>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.
>>
>>
I totaly agree, therefore I wrote (I don't like it)

>> >>   --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.
>>
>>
I thought it.

>> >
>> >>   --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 also think, that it is a most suitable way, how to solve it.
This was a reason, why it was placed at the end.
Nobody came with another solution, so we should do it this way.

>
>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?

Ticket created.
https://fedorahosted.org/sssd/ticket/1928

LS



More information about the sssd-devel mailing list