GNOME Bugzilla – Bug 443022
Linking order of evolution-exchange-storage and libldap is wrong
Last modified: 2009-05-29 21:19:23 UTC
In servers/Makefile.am we have: evolution_exchange_storage_LDADD = \ $(top_builddir)/mail/libexchangemail.la \ $(top_builddir)/addressbook/libexchangeaddressbook.la \ $(top_builddir)/calendar/libexchangecalendar.la \ $(top_builddir)/camel/camel-stub-marshal.lo \ $(LDAP_LIBS) \ $(EXCHANGE_STORAGE_LIBS) \ $(LIBEXCHANGE_LIBS) ... exchange_connector_setup_LDADD = \ $(LDAP_LIBS) \ $(EXCHANGE_STORAGE_LIBS) \ $(LIBEXCHANGE_LIBS) ... migr_test_LDADD = \ $(LDAP_LIBS) \ $(EXCHANGE_STORAGE_LIBS) \ $(LIBEXCHANGE_LIBS) The order of items in these stanzas has not changed since 2004 [1], yet a few weeks ago my Fedora builds of evolution-exchange 2.10.x and 2.11.x started mysteriously failing on 64-bit architectures with error messages such as: /usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../../lib64/libexchange-storage-1.2.so: undefined reference to `ldap_value_free' /usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../../lib64/libexchange-storage-1.2.so: undefined reference to `ldap_get_option' /usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../../lib64/libexchange-storage-1.2.so: undefined reference to `ldap_get_values_len' /usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../../lib64/libexchange-storage-1.2.so: undefined reference to `ldap_parse_result' /usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../../lib64/libexchange-storage-1.2.so: ... and on, and on ... The reason for this is because libexchange-storage-1.2 needs to link against libldap. But because we're linking against libldap *before* we link against libexchange-storage-1.2, the linker complains of unresolved ldap symbols in libexchange-storage-1.2. The solution is to place $(LDAP_LIBS) *last* in each of the three stanzas above. I'm at a loss to explain why it worked before, or why it was only failing on 64-bit architectures. It may or may not be relevant that we statically link against a custom openldap library that provides NTLM support. I could not find any significant changes to the packaging, source code, or build scripts of either the evolution-exchange or openldap packages between the last successful build and the first failed build. [1] http://svn.gnome.org/viewcvs/evolution-exchange/trunk/storage/Makefile.am?r1=87&r2=333
Created attachment 89205 [details] [review] Proposed patch This patch resolved the linker errors for me. I think I lost a year or two of my life struggling with this one.
I am not sure why your Fedora builds are failing, because, the OpenSuSE builds are just fine - including 64-bit versions. Can you once again check whether this is specific to Fedora or upstream issue? I will just mark the patch as reviewed - lets hold the commit till Matthew confirms the above.
To be honest, I'm not exactly sure what's going on with this. Best I can figure is the OpenSuSE (and probably other distro) builds are working by fluke. As I understand how linkers work, it resolves symbols in the order that libraries are listed. So when the linker gets to libexchange-storage, it should have already dealt with unresolved LDAP symbols when it linked in libldap. Any LDAP symbols appearing in subsequent libraries will remain unresolved. libexchange-storage must somehow be getting inadvertently pulled in before libldap, or else it's linking in libldap a second time later in the linking phase after libexchange-storage. I don't how that's happening, but apparently something changed on 64-bit architectures in Fedora to prevent it from happening. Swapping the linking order to be consistent with how it theoretically ought to be linking fixed the problem. I filed the bug upstream in case it eventually bites other distros. I guess you could try testing the patch on an OpenSuSE build. If it breaks the build then I'm full of hot air.
I also had to apply this patch to Evolution-Exchange in RHEL5 recently when it suddenly failed to rebuild. Something in our build environment changed but I still can't pin down what, or how it was working before. The current state of the Makefile.am in Subversion still seems broken to me even though it may manage to successfully build in OpenSuSE or other distros.
Similar type of linking order problem in bug #518728.
Similar type of linking order problem in bug #519234
(In reply to comment #6) > Similar type of linking order problem in bug #519234 No, not similar.
*cough* are we doing anything about this? I mean the changes seem to not break anything, yet look pretty good. Maybe we should commit the changes without being able to reproduce it.
I'll try a Feddora build without the patch. If it still fails to build without the patch I'll commit it.
Evolution-Exchange 2.27.2 built fine in Fedora without the patch, so I'm closing this bug as OBSOLETE. If the problem crops up again I'll reopen.