Gentoo Archives: gentoo-dev

From: "Diego 'Flameeyes' Pettenò" <flameeyes@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Fixing broken libtool/autotools handling
Date: Tue, 28 Mar 2006 06:06:48
1 Okay I suppose this was already in the TODO list of at least blubb and az but
2 they don't seem to have time, neither I do, but at least I'll try to put this
3 thing written down.
5 Currently we lack an "automated" way to fix packages that has broken or unsafe
6 handling of autotools or libtool.
7 The elibtoolize function -that should be called by every package that uses
8 libtool to build shared libraries- applies a series of patches to sanitize
9 the behaviour of libtool in some cases (for example to support uclibc or
10 Gentoo/FreeBSD).
12 Unfortunately, using elibtoolize requires
14 a) that the packages actually run it;
15 b) a lot of patches to be put inside portage.
17 This doesn't really scale too well, and it was proposed to merge elibtoolize
18 inside portage, so that it can be run automatically, but that was a problem
19 because it requires either to ship the patches within portage, or to make
20 portage aware of its tree's structure, or to make portage call the eclass.
22 Another proposed solution (by blubb iirc) was to make elibtoolize a package by
23 itself, shipping patches with it, and make portage depend on it.
25 I actually like this solution, but I would think it should be extended to fix
26 generically known broken behaviours of configure scripts that might be
27 related to broken tests. An example could be the tests that relies on
28 implicit declarations like of exit() that breaks when using stuff
29 like -Werror-implicit-declarations, or to broken config.* stuff...
31 Comments, thoughts?
33 --
34 Diego "Flameeyes" Pettenò -
35 Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


Subject Author
Re: [gentoo-dev] Fixing broken libtool/autotools handling Mike Frysinger <vapier@g.o>