+++ Wookey [2014-04-17 15:20 +0100]:
> +++ Russ Allbery [2014-04-16 11:42 -0700]:
> > Wookey <woo...@wookware.org> writes:
> >
> > > So, where in debian should we put responsiblity for updating
> > > config.{sub,guess}?
> >
> > I lean towards being more aggressive than this and running autoreconf or
> > the moral equivalent on any package using Autoconf, by default.
>
> Yes, I should have qualified my message to say 'this is only
> considering the easy, config-update part of this'.
>
> I too am in favour of full autoreconfing, for the reasons you covered.
OK. And, entirely by chance, up comes an example of why this is
thornier than it should be and this isn't as simple as 'either update
config.sub,guess, or autoreconf'. We have to do both, and the latter
doesn't necessarily do the former for us.
(Note I'm not picking on the libgc maintainer here - he's diligently
updated stuff like we asked and couldn't easily test any of the new
architecture cases - this is just a convenient example)
So libgc is a package where the maintainer has helpfully just uploaded
a version with "Run full autoconf during build (Closes: #732349)" -
i.e. did just what we've been recommending.
However it still FTBFS on arm64:
http://buildd.debian-ports.org/status/package.php?p=libgc&suite=sid
with: Invalid configuration `aarch64-linux-gnu': machine `aarch64' not
recognized
The maintainer has noted that upstream provides a non-trivial
autogen.sh script so has told dh_autoreconf to run that. This all
seems very sensible (although I get vague about the full implications
of this, it's certainly quite a common case). However the config.sub
and guess in the package are 2011-vintage and thus too old to know
about aarch64. (actually oddly, config.guess does know about it and
says 'you are on aarch64', but config.sub then says 'never heard of
it' and barfs - this pairing is perhaps a bug in itself, but as it
illustrates a wider point I'm not going to blame the maintainer - lets
just pretend they were both too old - it makes no practical
difference).
The issue here is ultimately that anything that uses upstream
autotools, rather than debian wrapping round it will _never find_ the
canononical distro config files in /usr/share/misc/config.{sub,guess}.
You can run autoreconf till you are blue in the face it'll never pick
up those files. dh_autotools-dev_updateconfig will, dh_autoreconf
should, but doesn't under all circs, possibly for good reasons.
So the core issue here is that because upstream autoconf have said
they don't want to look through a list of distro canonical paths,
(https://lists.gnu.org/archive/html/autoconf/2012-10/msg00036.html)
autoconf will never find our (uptodate) config.* files by itself. You
have to use some debian-foo to do that (or set the upstream magic env
var CONFIG_GUESS=path before calling configure). I tried setting the
magic var and it didn't work (possibly because the configure script is
too old).
So far as I can see the way to make this work the way it should is to
put Paul's 'and look in the debian paths' patch into the debian
version of autoconf. At which point any use of autoreconf should pick
them up (although I admit to being rather vague about exactly when
this will/won't work without some more poking about).
So (AIUI, which isn't that well) there are three parts to this
1) ensure uptodate config.* files are on the system at build time
2) ensure they get used
3) autoreconf things so all the other pieces are uptodate too.
Without all three of those things porting problems will persist.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140417170507.gi29...@stoneboat.aleph1.co.uk
