[collectd] Bug#535786: Change severity of 535786 to important

[Sebastian Harl]

Hi,

On Mon, Aug 31, 2009 at 09:22:49AM -0300, Rodrigo Campos wrote:
> On Mon, Aug 31, 2009 at 12:34:01PM +0200, Sebastian Harl wrote:
> > The problem is an error in the build system. collectd ships its own
> > version of libiptc (which is used by the iptables plugin) because this
> > library used to be available as a static lib only (which cannot be
> > linked into a shared object on most architectures). Starting with
> > version 1.4.3, iptables ships a shared library as well - however, with a
> > slightly modified API / ABI. Now, the problem is that the build system
> 
> It seems it should not change the ABI:
> 
> http://markmail.org/message/aqommixeonl5l5sj#query:netfilter%20libiptc+page:1+mid:fdxs37gp6e2igpto+state:results
> 
> Patrick said that in the second email of the thread.

Hrm … apparently he's wrong. However, the shipped version of libiptc has
been imported from iptables 1.4.1, so maybe this holds true for later
versions only. Here's an example of an incompatible change:

--- src/libiptc/libiptc.h
+++ /usr/include/libiptc/libiptc.h
[…]
@@ -44,41 +33,38 @@
 #define IPTC_LABEL_QUEUE   "QUEUE"
 #define IPTC_LABEL_RETURN  "RETURN"

-/* Transparent handle type. */
-typedef struct iptc_handle *iptc_handle_t;
[…]
 const struct ipt_entry *iptc_first_rule(const char *chain,
-                                       iptc_handle_t *handle);
+                                       struct iptc_handle *handle);

So, before that last argument was of type 'struct iptc_handle **' while
it's 'struct iptc_handle *' now. There are quite a few more examples
like this.

> Also, it seems a patch have been applied to deal with this (projects which use
> libiptc).

In that thread you pointed out, I could only find patches for the build
system to basically change 'noinst_LTLIBARIES' to 'lib_LTLIBRARIES' for
libiptc (i.e. install that library on 'make install' instead of making
it available for internal use only). Which patch did you have in mind?

> > uses the libiptc headers shipped with collectd (due to an unfortunate
> > include path) but links against the shared lib found in the system.
> > Unfortunately, the ABI changed in a way that linking would still work
> > but we get the segfault at runtime.
> > 
> > The following things need to be done to resolve that issue:
> 
> Just linking with a particular version of libiptc (if I don't misunderstand the
> link to the thread I paste) should be enough (and no need for the copy of
> libiptc in the repos).

Well, in Debian we won't need a copy of libiptc any longer but, being an
upstream developer as well, I think it still makes sense to ship the lib
in the upstream tarball since the shared libiptc is available for a
fairly short time only so far.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20090831/c7729a23/attachment.pgp