[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

The evil build methods of thy libev

Hi developers,

I am a non-DD member of the Debian Perl Group. In the process of packaging the
libev-perl package, an event loop for Perl, I stumbled upon the fact that it
does not link against libev as a shared object, but instead builds it into its
own binary.

libev has a "feature" that allows you to build it differently - changing some
structs to add customized fields - via a #define. Essentially, every included
libev is different than the other ones, therefore you can't simply get rid of
this by switching to dynamic linking.

I e-mailed upstream about this, but he basically considers this a feature and,
remembering of the OpenSSL fiasco, warned not to fiddle in upstream code.

As per Policy 3.8.0, packages should not include copies of other packages. I
think the best way would be to fix the library and provide another way to
include additional fields into its data structures, using the classic approach
of a pointer to userdata. However, that would require us to patch any application
using libev this way.

The second option I came up with was creating a libev-source package from the
existing libev package and build packages including libev against this one.
Bugs in libev would then only require a rebuild of the dependent packages
instead of source package fixing. I think this solution is suboptimal but less

AFAIK the only affected package currently in Debian is rxvt-unicode (see #512487).

From the README of libev:

   Examples of programs that embed libev: the EV perl module,
   rxvt-unicode, gvpe (GNU Virtual Private Ethernet), the Deliantra MMORPG
   server (http://www.deliantra.net/), Rubinius (a next-generation Ruby
   VM), the Ebb web server, the Rev event toolkit.

I have not checked whether the mentioned software includes libev or builds
against the dynamic library properly.

Maximilian Gaß

Attachment: signature.asc
Description: Digital signature

Reply to: