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@(a)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_... They set link_all_deplibs to "no". Fedora has default value "unknown", which is treated like "yes".

From the Debian patch:

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@(a)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_... 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)

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

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

On May 15, 2013, at 5:09 AM, Jakub Hrozek <jhrozek(a)redhat.com&gt; 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: &#39;_talloc_zero_array@(a)TALLOC_2.0.2&#39; 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_... >> 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).