After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 549025 - Building with Mono support causes main executable to linked against libmono
Building with Mono support causes main executable to linked against libmono
Product: evolution
Classification: Applications
Component: Plugins
2.24.x (obsolete)
Other All
: Normal normal
: ---
Assigned To: evolution-plugin-maintainers
Evolution QA team
Depends on:
Reported: 2008-08-22 15:54 UTC by Adam Williamson
Modified: 2008-10-22 14:15 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24

Proposed patch (2.33 KB, patch)
2008-10-21 16:09 UTC, Matthew Barnes
committed Details | Review

Description Adam Williamson 2008-08-22 15:54: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

Actual results:

Expected results:
Ideally, no result :)

Does this happen every time?

Other information:
Comment 1 Matthew Barnes 2008-10-21 14:46:25 UTC
Confirming.  Mono linkage should be restricted to the plugin, and the plugin should only be built with --enable-mono=yes.
Comment 2 Matthew Barnes 2008-10-21 16:09:28 UTC
Created attachment 121030 [details] [review]
Proposed patch

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.
Comment 3 Adam Williamson 2008-10-21 16:36:18 UTC
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?
Comment 4 Matthew Barnes 2008-10-21 16:58:23 UTC
None that I know of.  CC'ing Srini; maybe he knows of one.
Comment 5 Adam Williamson 2008-10-21 17:58:46 UTC
OK. Well, for now I can confirm the patch does what I wanted: isolates the libmono dep to the sub-package. Thanks a lot.
Comment 6 Srinivasa Ragavan 2008-10-22 02:57:21 UTC
Matt commit it anyways. Sankar has some sample mono plugins.
Comment 7 Matthew Barnes 2008-10-22 13:06:06 UTC
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.
Comment 8 Adam Williamson 2008-10-22 14:15:02 UTC
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.