GNOME Bugzilla – Bug 549025
Building with Mono support causes main executable to linked against libmono
Last modified: 2008-10-22 14:15:02 UTC
Please describe the problem:
A Mandriva forum member recently asked me why our Evolution package required libmono0 (our Mono library package). I looked into it. It turns out that when Evo is built with Mono support (for Mono plugins) enabled - even though this appears to generate three separate files which can easily be split out into a subpackage - it also causes the main evolution executable to be dynamically linked against libmono .
So the Mono dependency can't be restricted to an evolution-mono subpackage; as soon as you build Evolution with Mono support, the main package itself will always depend on libmono, even though it really doesn't use it for anything.
Would it be possible to improve this, so that Mono plugin support does not require the main executable to be dynamically linked against libmono, and we could ship an evolution package which does *not* depend on libmono and an evolution-mono package which does? Thanks.
Steps to reproduce:
1. Build Evo with mono support
2. ldd /usr/bin/evolution | grep mono
Ideally, no result :)
Does this happen every time?
Confirming. Mono linkage should be restricted to the plugin, and the plugin should only be built with --enable-mono=yes.
Created attachment 121030 [details] [review]
I think this should do it:
- On --enable-mono=no, the mono plugin is not built and libmono is not used.
- On --enable=mono=yes, the mono package is checked for and configure fails
if the package is not found. If the mono package _is_ found, the mono
plugin is built and only it links to libmono (not the main executable).
The patch also adds a couple configure summary lines indicating whether the Mono and Python bindings will be built.
Great, thanks. I can do a test build to check the dependencies. Is there an example / test Mono extension I can use to check that the plugin works as intended after the patch?
None that I know of. CC'ing Srini; maybe he knows of one.
OK. Well, for now I can confirm the patch does what I wanted: isolates the libmono dep to the sub-package. Thanks a lot.
Matt commit it anyways. Sankar has some sample mono plugins.
Committed to trunk (revision 36675).
I don't think I want to mess with this in 2.24. Distro maintainers can either grab this patch for themselves or disable mono at configure time. I chose the latter for Fedora.
Makes sense to me. I already committed it to Cooker in MDV; it's up to Fred whether to backport it as an update for our stable releases.