[collectd] collectd: how to solve the -fPIC problem on amd64

[Sebastian Harl]

Hi Milan,

On Wed, Oct 31, 2007 at 08:31:10PM +0100, Milan Krcmar wrote:
> recently, I've moved our main network router from Fedora i386 to a new
> amd64 machine and Etch. By a very nice accident I found the collectd
> package, sometheing I would else have to write by my own. It solves my
> need for rrd statistics of kernel's network queuing disciplines.

Very nice :-)

> I've been searching through Fedora's packages at first to know how
> "they" solve this. Whenever somebody fills in a bug that she is not able
> to build a dependent shared library on amd64, the Fedora team updates
> the dependency package simply recompiling the static library with -fPIC.
> Something you've failed with in Debian's bug tracking system (as it
> breaks Debian's "policies").

There are bugs against iptables-dev (and nut-dev, which suffers from the same
problem) - I did not have the time to write a clean patch for those packages
yet and the maintainers did not respond so far, so, unfortunately, there is
currently no way to build those plugins on amd64 Debian (unless you recompile
those packages yourself).

I did not file a bug against iproute-dev yet, but I've talked to the
maintainer and he promised to incorporate a patch as soon as I provide one.
I'm going to write that patch some time during the weekend.

> (1)
> 
> I tried to patch the iproute-dev package (which contains libnetlink.a)
> to bulid also the PIC version called libnetlink_pic.a.
> 
> Then I came to collectd. It can not be easily adjusted to link against
> libnetlink_pic.a instead of libnetlink.a. I had to change configure.in
> which in turn requires autotools while building the package: the
> Build-Depends would have to be extended with automake1.9, autoheader and
> libtool! Anyway, it gives me a result.

Well, this is not what you want in the long run as you basically have to
maintain a branch of collectd and iproute-dev. As I said before, an iproute
package will be available fairly soon including a PIC version of libnetlink
(however, this will not make it into Etch - I could provide backports though).
Also, I will patch the collectd build system to find the right library.

> (2)
> 
> Make the iproute package to build libnetlink as a shared library
> (libnetlink.so). This would in turn require the libnetlink binary
> package (not the libnetlink-dev) to contain the .so file. Ugly, not?

This is not going to happen. Imho it's not ugly but libnetlink does not seem
to be designed for that.

> (3)
> 
> Change the behavior of Debian's gcc/binutils on amd64 to search for
> libnetlink_pic.a when given the "-lnetlink" option _and_ building PIC
> code. This would be consistent with Debian's policy: if you discover
> a need for a static library to build a shared one, you patch the
> dependecy (the static package) to contain also the libsomething_pic.a but
> would not have to change anything in the dependent (shared lib) package.
> 
> I hope this is technically possible.

Uh, technically, it would be possible though, but it's a really bad hack imho.
And it's definitely not going to happen as well.

> (4)
> 
> Change the policy to allow for -fPIC in static libraries where it is
> really needed. The Fedora's way.

Well, there are basically two important things to know:

 a) -fPIC is only required if the static lib gets linked into a shared object
    (which should be a very rare case)

 b) on some systems (e.g. i386) using PIC code is more expensive (as in:
    requires more overhead and thus resources) than using non-PIC code

Thus I can perfectly understand (and agree with) the way Debian is doing this.
The policy does not forbid to ship additional packages that contain static
libs with PIC code which imho is the way to go in case PIC is really needed.

There is another solution / workaround:

(5)

Install collectd into an i386 chroot on your amd64 box. You can do this by
either putting together a very minimal system by copying all required
dependencies (libraries, etc.) to the chroot manually or by simply using
debootstrap to install a minimal Debian system to the chroot.

However, keep in mind that RRD files are architecture dependent, so you cannot
simply copy them back to amd64 later on. You can use rrdtool dump / restore to
convert the files.

> Will you recommend me one of these solutions, please? I suppose you both
> know the whole Debian world much better than me and are interested in
> solving this problem in collectd...

I'd probably go for (1) for now and wait for PIC enabled packages to appear in
Debian. If you do not want to maintain branches of the packages for that
period of time, I'd recommend (5).

> Thank you in advance. I am sorry for my inability to express myself in
> a shorter way in English.

Don't worry, I'm not a native speaker either ;-)

HTH,
Sebastian

PS: If you don't mind, I will bounce this message to collectd at verplant.org
(the official collectd mailinglist), so others can benefit as well).

-- 
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: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20071101/9b6159d7/attachment.pgp