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@(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)
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?