cyrus-imapd: static binaries are huge + choose binaries to install
Henrique de Moraes Holschuh
hmh at debian.org
Fri Jun 24 14:00:07 EDT 2011
On Fri, 24 Jun 2011, Bron Gondwana wrote:
> On Fri, Jun 24, 2011 at 06:27:22PM +0200, Luca Ceresoli wrote:
> > It looks like I'm not the first to think about this. In
> > http://bugzilla.cyrusimap.org/show_bug.cgi?id=3095
> > a patch was proposed and rejected. Unfortunately I could not apply
> > it, possibly because it's based on an old code base (2008).
> Yeah, the Makefiles have changed a fair bit in that time.
> > Would it be feasible to add shared build support in the cyrus-imapd
> > build system?
> I don't see any problem with this. I'd love for someone to do
> it. I have a pile of tasks that would be higher priority for
> me, but I'm happy to review changes.
I suggest going all the way and switching to latest GNU config,
autoconf, automake and libtool. While nasty, it will help a _lot_ with
the shared libraries and executables on several platforms, and distros
have the knowledge to force-fix libcrap into something that works when
The weird side-effect is that it will be _harder_ to have static
executables, though (.la files are hell). Not something we should care
cmake would work too, but cmake can be nasty when you need to do
crosscompilation and multiarch. I don't know how portable it is,
> executables. Nothing says you can't clean up your "install" after
> building it. I assume your build machine has space.
For the record, that's what we do in Debian: we separate Cyrus IMAPd
into various binary packages after the normal build.
> I have no objection to it, but I can't prioritise it over my other
> responsibilities, so someone else will have to do the work!
Sorry, I cannot offer my services to reautotool it, eihter :-(
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
More information about the Cyrus-devel