GNOME Bugzilla – Bug 571275
[KB-Fixed] Build failure: cannot link against modules
Last modified: 2009-08-30 05:53:18 UTC
The following idiom: >plugin_LTLIBRARIES = libfoo.la libbar.la >libfoo_la_LDFLAGS = -module >libbar_la_LIBADD = libfoo.la will bomb nicely when OS X gcc tries to compile/link libbar: >/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: libfoo.so is input for the dynamic link editor, is not relocatable by the static link editor again I see this all over the calendar, mail, and plugins Makefile.am settings, where one module tries to link against another. One can never link against something that was built with -module: on darwin, a runtime loadable module is a different filetype than a dynamic linker library, so it's not possible to link against the former. I don't know a thing about evo internals, so I don't know if the solution is to embed the same sources in multiple modules (libbar_la_SOURCES = foo.c instead of libbar_LA_LIBADD = libfoo.la), or to put them in a private-static noinst_LTLIBRARIES=libcommon.la or common_LTLIBRARIES=libcommon.la (*not* a -module) and then have both libfoo_la_LIBADD=libcommon.la libbar_la_LIBADD=libcommon.la. But somehow this whole module->module spaghetti needs to be totally avoided.
Not to mention all the circular dependencies we have among modules. This might not be solvable until we migrate from the mailer, calendar, etc. from being BonoboObjects to GTypeModules (see [1]). I think what each component needs is a clear separation of the backend/utility APIs and the dynamically loaded bits that drive them. We kind of already have this separation with contacts, calendar, tasks and memos since they mainly talk to the evolution-data-server process. But the mailer is one monolithic blob with no such separation. That's the tough one to solve. [1] http://www.go-evolution.org/KillBonobo
calendar/conduits/common/libecalendar_common_conduit is my first target. It's marked as a -module but is linked-against by libetodo_conduit, libememo_conduit, and libecalendar_conduit. It installs headers but no .conduit file, so it sounds like it's just a shared library. Looking at it's code, appears to be a simple library of convenience functions, no objects or shared data, so sounds ripe to become a normal library rather than a loadable module. Removing "-module -avoid-version" from libecalendar_common_conduit_la_LDFLAGS seems to get the whole calendar/conduits subdir buildable even if I also set -no-undefined. I guess because it's always been a public thing and is linked by other things, it needs to stay as a public shared lib rather than becoming an internal convenience lib, so it would need some interface-versioning flags.
There was some discussion on IRC yesterday about linking the major components (mailer, calendar, etc.) statically instead of dynamically once the kill-bonobo branch lands. That would fix the component-to-component and plugin-to-component linking issues.
See also bug #314946, which has some prototype patches to address this.
I think I have this solved on the kill-bonobo branch. Tentatively tagging as fixed.
The "kill-bonobo" branch has been merged into "master" and will debut as Evolution 2.29.1. We believe the branch has addressed the reported issue. If you find the issue still exists in version 2.29 or later please feel free to re-open this bug. Closing as FIXED.