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 <jhro...@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 _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel