[RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems

[Paul Wise]

Hi all,

So, Debian is in the process of bringing up our upcoming arm64 port.
Unfortunately we are also coming across lots of packages with rather
outdated config.guess and config.sub files (see links below). We could
patch every single package that contains config.guess and config.sub but
that would be a lot of effort that doesn't scale. We could also patch
our build tools but the problem would still exist for other distros.

I would like to get rid of this issue once and for all by making the
update process for config.guess and config.sub once per machine or once
per package instead of once per package.

My initial approach in 2009 was to patch config.guess and config.sub to
look for newer versions of themselves but the maintainer of these files
wasn't happy with that approach.

I recently re-contacted him about this issue and was suggested to patch
autoconf. The approach I have taken is to make autoconf-produced
configure scripts use the package-local config.guess/config.sub by
default and if that fails then find the newest config.guess/config.sub
in a number of paths on the system and use it. I am not very familiar
with autoconf internals, m4 or the intricacies of ancient shells, so I
would very much appreciate a review of both the approach and my initial
attempt at implementing this, please see the attached patch.

If anyone knows where config.guess and config.sub are installed on
common platforms like the various Linux or BSD distributions, please let
me know those locations. I have only the paths for Debian and Gentoo.

http://wookware.org/files/aarch64faillog
http://bugs.debian.org/689607
http://bugs.debian.org/689610
http://bugs.debian.org/689611
http://bugs.debian.org/689612
http://bugs.debian.org/689613
http://bugs.debian.org/689614
http://bugs.debian.org/689615
http://bugs.debian.org/689617
http://bugs.debian.org/689618
http://bugs.debian.org/689619
http://bugs.debian.org/689620
http://bugs.debian.org/689621

[Bob Friesenhahn]

Does simple replacement of config.guess and config.sub constitute a
useful "port" to this previously unencountered target? Is there
really any viable substitute for re-autotooling the packages, while
modifying configure.ac, Makefiles, and source code as found to be
required?

Bob

[Paul Wise]

Post by Bob Friesenhahn
Does simple replacement of config.guess and config.sub constitute a
useful "port" to this previously unencountered target?

Yes. The problem is that we have to repeat this process for every
package every time we want to bootstrap a new port or system. Or we can
change every package to replace config.guess/sub. Or we can change the
packaging building process for every distribution to replace
config.guess/sub. Or we can just change autoconf so that it creates
configure scripts that look for the latest config.guess/sub. I am
pursuing all of these approaches, starting at autoconf.

Post by Bob Friesenhahn
Is there really any viable substitute for re-autotooling the packages,
while modifying configure.ac, Makefiles, and source code as found to
be required?

Not as yet, I'm hoping my patch will become that in the very long term.

[Bob Friesenhahn]

Post by Paul Wise

Post by Bob Friesenhahn
Does simple replacement of config.guess and config.sub constitute a
useful "port" to this previously unencountered target?

Yes. The problem is that we have to repeat this process for every
package every time we want to bootstrap a new port or system. Or we can
change every package to replace config.guess/sub. Or we can change the
packaging building process for every distribution to replace
config.guess/sub. Or we can just change autoconf so that it creates
configure scripts that look for the latest config.guess/sub. I am
pursuing all of these approaches, starting at autoconf.

While replacing config.guess/sub gets over the first hurdle, there are
surely additional hurdles to be encountered which might render getting
past the first hurdle to be moot. For example, libtool (also embedded
in packages) includes platform-specific code keyed off of results from
config.guess. Many configure scripts include peculiar code keyed off
of results from config.guess.

There is really no solid solution other than performing proper
maintenance of the packages and sending patches to the upstream
maintainer.

For an exceedingly-rare platform like arm64, it is likely that the
early ports will be of rather low quality and that quality will not
improve until package maintainers take an interest, get access to
target hardware, and make sure that their package works well on that
target.

Bob

[Paul Wise]

Post by Bob Friesenhahn
While replacing config.guess/sub gets over the first hurdle, there are
surely additional hurdles to be encountered which might render getting
past the first hurdle to be moot.

Agreed, the key here is to not give up before starting. I'll probably
work on other issues as I find out about them. The copies of libtool
parts are probably the next thing to work on.

Post by Bob Friesenhahn
For example, libtool (also embedded in packages) includes
platform-specific code keyed off of results from config.guess. Many
configure scripts include peculiar code keyed off of results from
config.guess.

In that case I should revise my patch to always use the latest available
config.guess instead of always trying the one in the package first.
Thanks for the info, I was a bit worried about that issue.

Post by Bob Friesenhahn
There is really no solid solution other than performing proper
maintenance of the packages and sending patches to the upstream
maintainer.

That doesn't scale to 30K packages, each with different maintainers both
upstream and Debian. Not to mention all the other distros.

Post by Bob Friesenhahn
For an exceedingly-rare platform like arm64, it is likely that the
early ports will be of rather low quality and that quality will not
improve until package maintainers take an interest, get access to
target hardware, and make sure that their package works well on that
target.

The people who are working on arm64 are employees of ARM Ltd and have
many years of experience with ARM stuff in both Debian and upstream. I
trust them to get the port right the first time. As for the packages, I
would guess that the other 64-bit Debian ports (ia64, amd64 etc) we have
had would have fixed most 64-bitness issues years ago. I would hope that
the port will be ready by the time ARMv8 capable SoCs are shipping.

[Bob Friesenhahn]

Post by Paul Wise

Post by Bob Friesenhahn
Does simple replacement of config.guess and config.sub constitute a
useful "port" to this previously unencountered target?

Yes. The problem is that we have to repeat this process for every
package every time we want to bootstrap a new port or system. Or we can
change every package to replace config.guess/sub. Or we can change the

Would it help if Autoconf supported environment variables to support
specifying the config.guess and config.sub scripts to use (similar to
CONFIG_SITE and CONFIG_SHELL)? For example, there could be
CONFIG_SITE and CONFIG_SUB environment variables. This approach would
allow the package build wrapper to cause updated scripts to be used
without needing to replace stale files which might happen to be in the
package. It seems easier for the package build system to specify what
it wants to be used rather than hope that rules built into the package
will select the desired version.

Bob

[Bob Friesenhahn]

CONFIG_SITE and CONFIG_SHELL)? For example, there could be CONFIG_SITE and
CONFIG_SUB environment variables. This approach would allow the package

I meant CONFIG_GUESS and CONFIG_SUB of course. :-)

Bob

[Russ Allbery]

Post by Bob Friesenhahn
Does simple replacement of config.guess and config.sub constitute a
useful "port" to this previously unencountered target?

Believe it or not, yes, frequently it does.

Note that this is specifically in the context of Debian, which means that
all of these platforms are Linux and they're all using glibc. The
variation between systems is therefore much less than one might expect,
and less than a lot of packages using config.guess/config.sub are
adjusting for. There are a lot of packages that have one case that works
on all Linux systems, and those will generally work fine on a new Debian
architecture as long as config.guess/config.sub doesn't explode when
attempting to determine the triplet.

[Wookey]

Post by Russ Allbery

Post by Bob Friesenhahn
Does simple replacement of config.guess and config.sub constitute a
useful "port" to this previously unencountered target?

Believe it or not, yes, frequently it does.
Note that this is specifically in the context of Debian, which means that
all of these platforms are Linux and they're all using glibc.

Indeed. In more than 90% of cases this is all that was required,
assuming the package cross-built at all (currently everything is
cross-built as there is no actual arm64 hardware anywhere).

yes, a proper autoreconf is better for lots of reasons but it doesn't
really make any difference for our purposes.

Wookey

[Eric Blake]

Post by Paul Wise
Hi all,
So, Debian is in the process of bringing up our upcoming arm64 port.
Unfortunately we are also coming across lots of packages with rather
outdated config.guess and config.sub files (see links below). We could
patch every single package that contains config.guess and config.sub but
that would be a lot of effort that doesn't scale. We could also patch
our build tools but the problem would still exist for other distros.
I would like to get rid of this issue once and for all by making the
update process for config.guess and config.sub once per machine or once
per package instead of once per package.

Not to discourage you, but I still see a fundamental problem, where
things will just not scale for several more years (if ever). Your
proposed patch will have no effect on packages that were shipped with a
configure script generated by autoconf 2.69 or earlier (that is, they
would only affect new packages built with the as-yet-unreleased autoconf
2.70). Therefore, you STILL have to touch every single package that was
built with older toolchains to get them to take advantage of any new
self-upgrading code path built into a newer autoconf.

Post by Paul Wise
My initial approach in 2009 was to patch config.guess and config.sub to
look for newer versions of themselves but the maintainer of these files
wasn't happy with that approach.
I recently re-contacted him about this issue and was suggested to patch
autoconf. The approach I have taken is to make autoconf-produced
configure scripts use the package-local config.guess/config.sub by
default and if that fails then find the newest config.guess/config.sub
in a number of paths on the system and use it.

Is it safe enough to look at common system locations alone, or should we
also be attempting a network lookup for the latest canonical upstream
sources (of course, realizing that networking might not be available, so
we must not trigger fatal failure just because a machine is off the grid
at the time configure is run).

Post by Paul Wise
I am not very familiar
with autoconf internals, m4 or the intricacies of ancient shells, so I
would very much appreciate a review of both the approach and my initial
attempt at implementing this, please see the attached patch.

I haven't yet looked at the patch; it's non-trivial enough that it will
need copyright assignment to the FSF before it can even be considered.
But I'm first worried about the bigger implications of what you intend
to do about the fact that packages that were not built with autoconf
2.70 or later (assuming this patch makes it in) will still not benefit
from this patch.

[Paul Wise]

Post by Eric Blake
Not to discourage you, but I still see a fundamental problem, where
things will just not scale for several more years (if ever). Your
proposed patch will have no effect on packages that were shipped with a
configure script generated by autoconf 2.69 or earlier (that is, they
would only affect new packages built with the as-yet-unreleased autoconf
2.70). Therefore, you STILL have to touch every single package that was
built with older toolchains to get them to take advantage of any new
self-upgrading code path built into a newer autoconf.

I acknowledge this problem and there is no way to get around it.
The patch is not meant to be useful for arm64, I'm taking a much longer
term view here, the benefit is perhaps 5-10 years away. Once the patch
is in a released version of autoconf it will percolate through the
distributions archives as projects autoreconf with the latest autoconf
and make new releases. Eventually we will have good coverage in most
distributions. In the meantime, within Debian we will be pursuing both
per-package updating of config.guess/sub and I'm also thinking about
getting our binary package build toolchain to take that role, but I'm
not sure how well that would be received within Debian or how well it
would work.

Post by Eric Blake
Is it safe enough to look at common system locations alone, or should we
also be attempting a network lookup for the latest canonical upstream
sources (of course, realizing that networking might not be available, so
we must not trigger fatal failure just because a machine is off the grid
at the time configure is run).

For Debian, network access is usually disabled on our build daemons.
I would discourage this without some checking of GPG signatures,
otherwise it would be easy for network attackers to get arbitrary code
execution on people's laptops and distribution build servers.

Post by Eric Blake
I haven't yet looked at the patch; it's non-trivial enough that it will
need copyright assignment to the FSF before it can even be considered.

Personally I don't consider the patch to contain any creativity or to be
copyrightable. I therefore consider that it is in the public domain and
to the extent possible under law, I have waived[CC0] all copyright and
related or neighboring rights to this work. If that isn't good enough
for the FSF, then I'm willing to assign copyright as needed.

CC0: http://creativecommons.org/publicdomain/zero/1.0/

Post by Eric Blake
But I'm first worried about the bigger implications of what you intend
to do about the fact that packages that were not built with autoconf
2.70 or later (assuming this patch makes it in) will still not benefit
from this patch.

I hope I've addressed them to your satisfaction above.

[Russ Allbery]

In the meantime, within Debian we will be pursuing both per-package
updating of config.guess/sub and I'm also thinking about getting our
binary package build toolchain to take that role, but I'm not sure how
well that would be received within Debian or how well it would work.

Personally, I've already started converting every package I maintain that
uses Autoconf to using dh_autoreconf during the build. I wonder if that
isn't a better long-term solution for Debian. config.guess/config.sub
have caused the most frequent problems, but we've had problems in the past
from old versions of Libtool as well, and dh_autoreconf resolves the
entire problem (at least for packages for which it works).

Paul, separately, if you haven't already, could you request that the
Lintian checks for outdated config.guess/config.sub be updated for
whatever version you need for arm64? We could also recommend
dh_autoreconf at the same time, which might resolve a lot of these
problems going forward.

[Henrique de Moraes Holschuh]

Post by Russ Allbery
Personally, I've already started converting every package I maintain that
uses Autoconf to using dh_autoreconf during the build. I wonder if that
isn't a better long-term solution for Debian. config.guess/config.sub
have caused the most frequent problems, but we've had problems in the past
from old versions of Libtool as well, and dh_autoreconf resolves the
entire problem (at least for packages for which it works).
Paul, separately, if you haven't already, could you request that the
Lintian checks for outdated config.guess/config.sub be updated for
whatever version you need for arm64? We could also recommend
dh_autoreconf at the same time, which might resolve a lot of these
problems going forward.

Well, as far as I am concerned, we should axe from the [next] Debian stable
distro anything that doesn't retool completely before the build, IMO just
updating config.sub/guess is not nearly enough.

That said, Debian rules for packages *really* won't help a large class of
people: those who are not doing Debian package work...

And BTW, I am perfectly fine with issuing debian-stable updates to
autotools-dev (the Debian package that contains the /usr/share/misc/
config.{sub,guess}), but someone has to convince the release managers that
this is acceptable. We _really_ should do this, since people do develop
software using Debian...

[Paul Wise]

Post by Henrique de Moraes Holschuh
Well, as far as I am concerned, we should axe from the [next] Debian stable
distro anything that doesn't retool completely before the build, IMO just
updating config.sub/guess is not nearly enough.

I think thats going a bit far, especially since there is widely varying
opinion within Debian about if retooling is a good idea or not. I think
retooling is important for various reasons but not important enough to
lose the software from maintainers who disagree.

Post by Henrique de Moraes Holschuh
That said, Debian rules for packages *really* won't help a large class of
people: those who are not doing Debian package work...

Good point!

Post by Henrique de Moraes Holschuh
And BTW, I am perfectly fine with issuing debian-stable updates to
autotools-dev (the Debian package that contains the /usr/share/misc/
config.{sub,guess}), but someone has to convince the release managers that
this is acceptable. We _really_ should do this, since people do develop
software using Debian...

I think they would be open to this. Please file a bug so we can get this
into the next point release:

http://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable

[Paul Wise]

Post by Russ Allbery
Personally, I've already started converting every package I maintain that
uses Autoconf to using dh_autoreconf during the build.

Likewise.

Post by Russ Allbery
I wonder if that isn't a better long-term solution for Debian.

It is, but for DFSG item 2 reasons rather than this. As a solution for
this in Debian and outside Debian I don't think it scales as well.
Within Debian we would need to make everything use debhelper and make
debhelper do it by default, neither of which are likely. There are quite
a few distros, including proprietary ones, so I don't think this
approach scales outside of Debian either.

Post by Russ Allbery
config.guess/config.sub have caused the most frequent problems, but
we've had problems in the past from old versions of Libtool as well,
and dh_autoreconf resolves the entire problem (at least for packages
for which it works).

Thanks, I guess I should prepare a patch for the libtool artefacts too.

Post by Russ Allbery
Paul, separately, if you haven't already, could you request that the
Lintian checks for outdated config.guess/config.sub be updated for
whatever version you need for arm64? We could also recommend
dh_autoreconf at the same time, which might resolve a lot of these
problems going forward.

Thanks for the suggestion, filed:

http://bugs.debian.org/690014

[Adrian Bunk]

Post by Paul Wise

Post by Russ Allbery
Personally, I've already started converting every package I maintain that
uses Autoconf to using dh_autoreconf during the build.

Likewise.

Post by Russ Allbery
I wonder if that isn't a better long-term solution for Debian.

It is, but for DFSG item 2 reasons rather than this. As a solution for
this in Debian and outside Debian I don't think it scales as well.
Within Debian we would need to make everything use debhelper and make
debhelper do it by default, neither of which are likely. There are quite
a few distros, including proprietary ones, so I don't think this
approach scales outside of Debian either.
...

One problem is that in new upstream versions of autoconf/automake/libtool
there are sometimes slight incompatibilities, and you end up with
shipping many different versions of each of these tools (even today
Debian already ships 5 different versions of autoconf).

E.g. putting automake 1.13 [1] as automake package into Debian would
then require updating thousands of packages just for getting the whole
archive to build again.

Post by Paul Wise
bye,
pabs

cu
Adrian

[1] That will remove quite a few things marked as obsolete.

[Russ Allbery]

Post by Adrian Bunk
One problem is that in new upstream versions of
autoconf/automake/libtool there are sometimes slight incompatibilities,
and you end up with shipping many different versions of each of these
tools (even today Debian already ships 5 different versions of
autoconf).
E.g. putting automake 1.13 [1] as automake package into Debian would
then require updating thousands of packages just for getting the whole
archive to build again.

This is a lot of work, yes. But personally I think it's valuable work
that we shouldn't shy away from, and with which we can often help
upstream. We do the same thing each time a new g++ is released; I don't
think there's been a major g++ release that hasn't required some patches
to one of the C++ packages I maintain.

(autoconf-dickey is a separate matter; at this point, I think it's best to
treat that as a permanent fork.)

[Adrian Bunk]

Post by Russ Allbery

Post by Adrian Bunk
One problem is that in new upstream versions of
autoconf/automake/libtool there are sometimes slight incompatibilities,
and you end up with shipping many different versions of each of these
tools (even today Debian already ships 5 different versions of
autoconf).
E.g. putting automake 1.13 [1] as automake package into Debian would
then require updating thousands of packages just for getting the whole
archive to build again.

This is a lot of work, yes. But personally I think it's valuable work
that we shouldn't shy away from, and with which we can often help
upstream.
...

Debian unstable usually contains code from the upstream stable branch,
and even from that the latest release is often a few months old (no new
upstream release or the latest is not yet in Debian).

The issue might often already be fixed in the latest upstream unstable
development, and it could easily result in most of the work being
cherry-picking patches that are already upstream.

Post by Russ Allbery
...
(autoconf-dickey is a separate matter; at this point, I think it's best to
treat that as a permanent fork.)

(I'm currently working with Thomas towards getting more of his packages
buildable with autoconf 2.69)

cu
Adrian

BTW: Please send a copy of the mail to me when you reply to emails from me.

[Paul Wise]

Post by Paul Wise
So, Debian is in the process of bringing up our upcoming arm64 port.
Unfortunately we are also coming across lots of packages with rather
outdated config.guess and config.sub files (see links below).

I've taken on board advice received during this thread and elsewhere and
updated the patch to always use the latest config.guess and config.sub
files. I've also tested the result on one of the things I'm upstream for
and it works to my satisfaction. The only downside is that there is a
code block that occurs twice in each generated configure script, but I'm
not sure how to avoid that, any pointers? Please see the attached patch.

[Eric Blake]

Post by Paul Wise

Post by Paul Wise
So, Debian is in the process of bringing up our upcoming arm64 port.
Unfortunately we are also coming across lots of packages with rather
outdated config.guess and config.sub files (see links below).

I've taken on board advice received during this thread and elsewhere and
updated the patch to always use the latest config.guess and config.sub
files. I've also tested the result on one of the things I'm upstream for
and it works to my satisfaction. The only downside is that there is a
code block that occurs twice in each generated configure script, but I'm
not sure how to avoid that, any pointers? Please see the attached patch.

I still prefer the idea of being able to set an environment variable,
$CONFIG_GUESS, rather than going hunting ourselves. Then, porting to a
new config.guess script is a matter of calling:

./configure CONFIG_GUESS=/path/to/new/version

rather than hoping that a hard-coded hunt will find the new config.guess
appropriate for the system wanting the upgrade path.

[Paul Wise]

Post by Eric Blake
I still prefer the idea of being able to set an environment variable,
$CONFIG_GUESS, rather than going hunting ourselves. Then, porting to a
./configure CONFIG_GUESS=/path/to/new/version
rather than hoping that a hard-coded hunt will find the new config.guess
appropriate for the system wanting the upgrade path.

Changing the command-line to ./configure doesn't scale. Exporting an
environment variable possibly sounds like an approach some folks would
need, so I have added it in the attached patch. For Debian it would be
easiest to just install the autotools-dev package in build chroots
(config.guess and config.sub are placed in /usr/share/misc) since it
doesn't require fiddling about with configuration files for build daemon
software, which usually doesn't leak random environment variables into
the build process.

[Eric Blake]

Post by Paul Wise

Post by Eric Blake
I still prefer the idea of being able to set an environment variable,
$CONFIG_GUESS, rather than going hunting ourselves. Then, porting to a
./configure CONFIG_GUESS=/path/to/new/version
rather than hoping that a hard-coded hunt will find the new config.guess
appropriate for the system wanting the upgrade path.

Changing the command-line to ./configure doesn't scale. Exporting an
environment variable possibly sounds like an approach some folks would
need,

Then call:

CONFIG_GUESS=/path/to/new/version ./configure

and make CONFIG_GUESS a precious variable within configure.

Post by Paul Wise
so I have added it in the attached patch. For Debian it would be
easiest to just install the autotools-dev package in build chroots
(config.guess and config.sub are placed in /usr/share/misc) since it
doesn't require fiddling about with configuration files for build daemon
software, which usually doesn't leak random environment variables into
the build process.

I still stand by my opinion that an env-var is sufficient, and we do not
need a path walk.

[Roger Leigh]

Post by Eric Blake

Post by Paul Wise

Post by Paul Wise
So, Debian is in the process of bringing up our upcoming arm64 port.
Unfortunately we are also coming across lots of packages with rather
outdated config.guess and config.sub files (see links below).

I've taken on board advice received during this thread and elsewhere and
updated the patch to always use the latest config.guess and config.sub
files. I've also tested the result on one of the things I'm upstream for
and it works to my satisfaction. The only downside is that there is a
code block that occurs twice in each generated configure script, but I'm
not sure how to avoid that, any pointers? Please see the attached patch.

I still prefer the idea of being able to set an environment variable,
$CONFIG_GUESS, rather than going hunting ourselves. Then, porting to a
./configure CONFIG_GUESS=/path/to/new/version
rather than hoping that a hard-coded hunt will find the new config.guess
appropriate for the system wanting the upgrade path.

This does not solve the problem. You still then have to update
up to 30K packages to run configure with this new argument. While
using an env var is fine to override the default behaviour, this is
really somewhere where having it behave sensibly by default without
any special action is required. Is defaulting to checking in
standard places like $datadir/misc so difficult? Are there any
significant downsides to doing so? Long-term, having configure
pick up a current config.guess/sub (and libtool) is something of
enormous benefit, because the current approach of embedding them
causes more problems than it solves.


Regards,
Roger

[Eric Blake]

Post by Roger Leigh

Post by Eric Blake
I still prefer the idea of being able to set an environment variable,
$CONFIG_GUESS, rather than going hunting ourselves. Then, porting to a
./configure CONFIG_GUESS=/path/to/new/version
rather than hoping that a hard-coded hunt will find the new config.guess
appropriate for the system wanting the upgrade path.

This does not solve the problem. You still then have to update
up to 30K packages to run configure with this new argument.

No, you don't. If CONFIG_GUESS is a precious variable, then you can set
it in your environment before running configure on any of those 30k
packages, instead of having to add it to 30k individual command lines.

Post by Roger Leigh
While
using an env var is fine to override the default behaviour, this is
really somewhere where having it behave sensibly by default without
any special action is required. Is defaulting to checking in
standard places like $datadir/misc so difficult?

Because it's too hard-coded, compared to the flexibility of an env-var.
Why does 'make' honor $CC instead of probing a hard-coded list? For
the same reason.

Post by Roger Leigh
Are there any
significant downsides to doing so?

Yes, complexity. Since an env-var already solves the solution, we don't
need the added complexity of also probing for fixed locations.

Post by Roger Leigh
Long-term, having configure
pick up a current config.guess/sub (and libtool) is something of
enormous benefit, because the current approach of embedding them
causes more problems than it solves.

Indeed, and that's why adding support for $CONFIG_GUESS sounds like a
good idea.

[Adrian Bunk]

Post by Roger Leigh

Post by Eric Blake

Post by Paul Wise

Post by Paul Wise
So, Debian is in the process of bringing up our upcoming arm64 port.
Unfortunately we are also coming across lots of packages with rather
outdated config.guess and config.sub files (see links below).

I've taken on board advice received during this thread and elsewhere and
updated the patch to always use the latest config.guess and config.sub
files. I've also tested the result on one of the things I'm upstream for
and it works to my satisfaction. The only downside is that there is a
code block that occurs twice in each generated configure script, but I'm
not sure how to avoid that, any pointers? Please see the attached patch.

I still prefer the idea of being able to set an environment variable,
$CONFIG_GUESS, rather than going hunting ourselves. Then, porting to a
./configure CONFIG_GUESS=/path/to/new/version
rather than hoping that a hard-coded hunt will find the new config.guess
appropriate for the system wanting the upgrade path.

This does not solve the problem. You still then have to update
up to 30K packages to run configure with this new argument. While
using an env var is fine to override the default behaviour, this is
really somewhere where having it behave sensibly by default without
any special action is required. Is defaulting to checking in
standard places like $datadir/misc so difficult? Are there any
significant downsides to doing so? Long-term, having configure
pick up a current config.guess/sub (and libtool) is something of
enormous benefit, because the current approach of embedding them
causes more problems than it solves.

The sensible action is to use the known-working versions that are
shipped by default.

Picking up newer, or older, or oddly patched, versions of such tools
that happen to be installed on the system has a high probability of
causing breakages.

As an example, there were many packages that needed small updates when
switching from libtool 1.5 to libtool 2.2.

Building packages on a new platform is a special case, and should be
treated as such without introducing new problems in the default case.

Post by Roger Leigh
Regards,
Roger

cu
Adrian

[Ralf Corsepius]

Post by Paul Wise

Post by Paul Wise
So, Debian is in the process of bringing up our upcoming arm64 port.
Unfortunately we are also coming across lots of packages with rather
outdated config.guess and config.sub files (see links below).

I've taken on board advice received during this thread and elsewhere and
updated the patch to always use the latest config.guess and config.sub
files. I've also tested the result on one of the things I'm upstream for
and it works to my satisfaction. The only downside is that there is a
code block that occurs twice in each generated configure script, but I'm
not sure how to avoid that, any pointers? Please see the attached patch.

I don't like this approach, because I think you are missing that
config.sub and config.guess have only been overwritten as part of
"autoreconf -f" (and not of "autoreconf"). This allows package upstreams
to implement customized versions of both of these scripts.

Though such cases are rare to find in mainstream packages, theses case
are quite common in cases to toolchain/OS implementors and
cross-compilation scenarios.


FWIW: Apart of this, in comparable situations in the past, on Red Hat
based distros, IIRC, RedHat had chosen to copy their versions of
config.guess+config.sub as part of their build-process [1] by
default[2]. This would be comparable to the dh_<something> others
mentioned before in this thread.

Ralf

[1] This copying operation was part of rpm's %configure.
Meanwhile, Red Hat/Fedora relies on packages to providing suitable
config.{guess,sub}s themselves, i.e. either "suiteable versions", or
"autoreconf -f" or patching.

[2] I.e. there were ways to allow packages to use their own
config.{guess,sub}.

[Paul Wise]

Post by Ralf Corsepius
I don't like this approach, because I think you are missing that
config.sub and config.guess have only been overwritten as part of
"autoreconf -f" (and not of "autoreconf"). This allows package upstreams
to implement customized versions of both of these scripts.

I hadn't considered custom versions, but that sounds icky. I figure in
these cases they can bump their timestamp to 9999-99-99 if they want to
never use the official versions of these files, I can't think of a case
where they would want that though. The use-cases you mention below, they
probably just want the latest versions from config.git rather than to
always use their own.

Post by Ralf Corsepius
Though such cases are rare to find in mainstream packages, theses case
are quite common in cases to toolchain/OS implementors and
cross-compilation scenarios.

I think people needing these particular use-cases can use my proposed
mechanism instead, which should work better for them anyway since they
don't need to modify every package being built nor modify their build
system.

Post by Ralf Corsepius
FWIW: Apart of this, in comparable situations in the past, on Red Hat
based distros, IIRC, RedHat had chosen to copy their versions of
config.guess+config.sub as part of their build-process [1] by
default[2]. This would be comparable to the dh_<something> others
mentioned before in this thread.

Could you give some more details? Were the RH versions of config.guess
and config.sub modified in any way or were they just newer versions from
GNU config CVS/git?

PS: Please CC me in reply.

[Mike Frysinger]

Post by Paul Wise
So, Debian is in the process of bringing up our upcoming arm64 port.
Unfortunately we are also coming across lots of packages with rather
outdated config.guess and config.sub files (see links below). We could
patch every single package that contains config.guess and config.sub but
that would be a lot of effort that doesn't scale. We could also patch
our build tools but the problem would still exist for other distros.

yes, Gentoo fixed this for every package in our tree like 9 years ago (we added
a common function like 11 years ago that ebuilds could call manually, but we
found that didn't scale). when you run a standard autoconf script, we
automatically search for files named "config.sub" and "config.guess" and replace
them with the up-to-date host copy. no checking or anything :). in
hindsight, that seems like a bad idea, but in practice, i think we have yet to
find a package that this doesn't actually work.

and behold, no one has ever complained about config.sub not recognizing their
mips or sparc or x86_64 or aarch64 system ever again.

Post by Paul Wise
If anyone knows where config.guess and config.sub are installed on
common platforms like the various Linux or BSD distributions, please let
me know those locations. I have only the paths for Debian and Gentoo.

if Gentoo is the only one that uses /usr/share/gnuconfig/ and every one else
picked /usr/share/misc/, then i'll just move Gentoo. don't bother listing it
in your patch. even then, many of the other paths (like internal
automake/libtool) will work fine on Gentoo.

we picked .../gnuconfig/ as it installs more than one file and FHS generally
recommends that packages w/more than one file not go into .../misc/.
-mike

[Ralf Corsepius]

Post by Mike Frysinger

Post by Paul Wise
So, Debian is in the process of bringing up our upcoming arm64 port.
Unfortunately we are also coming across lots of packages with rather
outdated config.guess and config.sub files (see links below). We could
patch every single package that contains config.guess and config.sub but
that would be a lot of effort that doesn't scale. We could also patch
our build tools but the problem would still exist for other distros.

yes, Gentoo fixed this for every package in our tree like 9 years ago (we added
a common function like 11 years ago that ebuilds could call manually, but we
found that didn't scale). when you run a standard autoconf script, we
automatically search for files named "config.sub" and "config.guess" and replace
them with the up-to-date host copy. no checking or anything :). in
hindsight, that seems like a bad idea, but in practice, i think we have yet to
find a package that this doesn't actually work.

Well, I can't imagine a case affecting config.guess, but constructing
cases affecting config.sub is pretty simple.

Classical use-case is developing on cross-built packages, which require
a new host/target-tuple and therefore ship a customized/modified config.sub.

Those cases are rare in publicly available/released packages, but they
are not uncommon in the toolchain/OS developer's community. Think about
working on "cfin-MikeOS" toolchain in binutils/gcc/gdb or adding support
for it to other auto*tools-based package ;)

At least for RTEMS, we had once carried such a customized config.sub for
a short period time.

Ralf

[Mike Frysinger]

Post by Ralf Corsepius

Post by Mike Frysinger

Post by Paul Wise
So, Debian is in the process of bringing up our upcoming arm64 port.
Unfortunately we are also coming across lots of packages with rather
outdated config.guess and config.sub files (see links below). We could
patch every single package that contains config.guess and config.sub but
that would be a lot of effort that doesn't scale. We could also patch
our build tools but the problem would still exist for other distros.

yes, Gentoo fixed this for every package in our tree like 9 years ago (we
added a common function like 11 years ago that ebuilds could call
manually, but we found that didn't scale). when you run a standard
autoconf script, we automatically search for files named "config.sub"
and "config.guess" and replace them with the up-to-date host copy. no
checking or anything :). in hindsight, that seems like a bad idea, but
in practice, i think we have yet to find a package that this doesn't
actually work.

Well, I can't imagine a case affecting config.guess, but constructing
cases affecting config.sub is pretty simple.
Classical use-case is developing on cross-built packages, which require
a new host/target-tuple and therefore ship a customized/modified config.sub.

i take the stance that if you haven't merged your code into the GNU config
project, then you deserve to break. or at least, you're too bleeding edge to
be merged into mainline Gentoo (which, honestly, is saying something). i keep
the snapshots in Gentoo up to date every few months, or someone asks for it
sooner (as they just got a change merged), so there's very little to no delay
syncing there.

and counter point: if someone wants to use e.g. Gentoo to develop things
early, they can also tweak the host system's gnuconfig package and then *all*
the Gentoo ebuilds now build correctly for your target :).
-mike

[Ralf Corsepius]

Post by Mike Frysinger

Post by Ralf Corsepius

Post by Mike Frysinger

Post by Paul Wise
So, Debian is in the process of bringing up our upcoming arm64 port.
Unfortunately we are also coming across lots of packages with rather
outdated config.guess and config.sub files (see links below). We could
patch every single package that contains config.guess and config.sub but
that would be a lot of effort that doesn't scale. We could also patch
our build tools but the problem would still exist for other distros.

yes, Gentoo fixed this for every package in our tree like 9 years ago (we
added a common function like 11 years ago that ebuilds could call
manually, but we found that didn't scale). when you run a standard
autoconf script, we automatically search for files named "config.sub"
and "config.guess" and replace them with the up-to-date host copy. no
checking or anything :). in hindsight, that seems like a bad idea, but
in practice, i think we have yet to find a package that this doesn't
actually work.

Well, I can't imagine a case affecting config.guess, but constructing
cases affecting config.sub is pretty simple.
Classical use-case is developing on cross-built packages, which require
a new host/target-tuple and therefore ship a customized/modified config.sub.

i take the stance that if you haven't merged your code into the GNU config
project, then you deserve to break.

Well, config.sub has allways been amongst those files the autotools
supposed not to be generated.

That said, if you replace them by brute-force, you are breaking the UI
of the autotools - Read: an utterly bad idea. RH/Fedora has done this
for a very long time and has given up doing so for several years, and
now is relying on packagers explicitly replacing them (autoreconf -f
rsp. by patching).

A better approach would be to only replace them, if they you are sure,
they are unmodified.

Post by Mike Frysinger
or at least, you're too bleeding edge to
be merged into mainline Gentoo (which, honestly, is saying something).

<comments non-disclosed/>

Ralf

[Mike Frysinger]

Post by Ralf Corsepius

Post by Mike Frysinger

Post by Ralf Corsepius

Post by Mike Frysinger

Post by Paul Wise
So, Debian is in the process of bringing up our upcoming arm64 port.
Unfortunately we are also coming across lots of packages with rather
outdated config.guess and config.sub files (see links below). We could
patch every single package that contains config.guess and config.sub
but that would be a lot of effort that doesn't scale. We could also
patch our build tools but the problem would still exist for other
distros.

yes, Gentoo fixed this for every package in our tree like 9 years ago
(we added a common function like 11 years ago that ebuilds could call
manually, but we found that didn't scale). when you run a standard
autoconf script, we automatically search for files named "config.sub"
and "config.guess" and replace them with the up-to-date host copy. no
checking or anything :). in hindsight, that seems like a bad idea,
but in practice, i think we have yet to find a package that this
doesn't actually work.

Well, I can't imagine a case affecting config.guess, but constructing
cases affecting config.sub is pretty simple.
Classical use-case is developing on cross-built packages, which require
a new host/target-tuple and therefore ship a customized/modified config.sub.

i take the stance that if you haven't merged your code into the GNU
config project, then you deserve to break.

Well, config.sub has allways been amongst those files the autotools
supposed not to be generated.
That said, if you replace them by brute-force, you are breaking the UI
of the autotools - Read: an utterly bad idea. RH/Fedora has done this
for a very long time and has given up doing so for several years, and
now is relying on packagers explicitly replacing them (autoreconf -f
rsp. by patching).

i understand the point you're making. however, ~10 years of building from
source in Gentoo and doing this for every single build has shown that in
practice, it's irrelevant. we've found exactly one package where this made a
slight difference (gmp), and even then it was a matter of selecting optional
optimizations that we can control via other routes.
-mike

[Warren Young]

Post by Mike Frysinger
i understand the point you're making. however, ~10 years of building from
source in Gentoo and doing this for every single build has shown that in
practice, it's irrelevant.

It's irrelevant *for* *Gentoo*. Not all autoconfiscated source trees
are in Gentoo.

I wouldn't be surprised if there were an iceberg effect here: it could
well be that ~90% of all source trees using the autotools aren't even
publicly visible, much less incorporated into the major Linux distros.

There's some self-selection bias going on here, too. Software that
fails to build in the Gentoo build system obviously won't get adopted
into Gentoo, if no one bothers to try and fix the breakage.

For what it's worth, I'm not entirely against your position. I do a bit
of packaging work for Cygwin, and we've got the same core problem over
there, too, particularly with the nascent Cygwin 64 effort.

[Mike Frysinger]

Post by Warren Young

Post by Mike Frysinger
i understand the point you're making. however, ~10 years of building
from source in Gentoo and doing this for every single build has shown
that in practice, it's irrelevant.

It's irrelevant *for* *Gentoo*. Not all autoconfiscated source trees
are in Gentoo.

... which is what this sub thread was focusing on, with the only slightly
bigger picture being distro packaging behavior. no, not *all* autotool based
packages are in Gentoo, but we've got pretty good coverage for anything
passably relevant (and then some).

Post by Warren Young
I wouldn't be surprised if there were an iceberg effect here: it could
well be that ~90% of all source trees using the autotools aren't even
publicly visible, much less incorporated into the major Linux distros.

then they're irrelevant to this sub thread.

Post by Warren Young
There's some self-selection bias going on here, too. Software that
fails to build in the Gentoo build system obviously won't get adopted
into Gentoo, if no one bothers to try and fix the breakage.

obviously that's possible, but i'm fairly certain it's unlikely. when things
break w/Gentoo, our devs/users tend to file bugs.

even then, writing your own config.sub is not something to be taken lightly.
the amount of blood/sweat/tears that have gone into maintaining that database
dwarfs whatever tiny project random person is working on. and even even then,
the number of people who even understand htf autotools work let alone a tiny
internal nuance like config.sub is fairly (if not extremely) esoteric.

if Gentoo blowing away your rinky dinky config.sub hack breaks your project,
then take it as a sign that You're Doing It Wrong :).
-mike

[Russ Allbery]

Post by Mike Frysinger
if Gentoo blowing away your rinky dinky config.sub hack breaks your
project, then take it as a sign that You're Doing It Wrong :).

I think this may be one of those historical momentum things. As INN
maintainer, I used to carry local patches to config.guess and config.sub
to add support for platforms on which my users were trying to build INN
that weren't supported by the current config.guess and config.sub scripts,
usually because the patches had been submitted but they were very slow to
release a new version. This problem went away completely some time back,
with a new and far faster and more responsive process for maintaining
those scripts, and now I just use the most recent released versions for
all packages. Some projects may still be carrying unnecessary hacks
because they started carrying them back in those days and have never gone
back and revisited.

[Warren Young]

we've got pretty good coverage for anything passably relevant (and then some).

So, because Gentoo has N text editors in the repo, the N+1th text editor
must port to Gentoo without problems?

You're committing a logical fallacy here, hasty generalization. "All
things in class A have property B, hence all things have property B."

The packages in Gentoo are ipso facto packages that *can* port to
Gentoo. You can't infer from that that all packages port to Gentoo
without requiring adjustment.

Post by Warren Young
I wouldn't be surprised if there were an iceberg effect here: it could
well be that ~90% of all source trees using the autotools aren't even
publicly visible, much less incorporated into the major Linux distros.

then they're irrelevant to this sub thread.

Why?

You propose changing the way autoconf works based on a sampling of
projects using it. A large sampling to be sure, but probably not
anywhere near a majority of those using autotools.

You *think* you know how your change will affect all those projects you
don't get to see, but you do not actually know, because you're working
from a biased sample. (Biased because it's an inherently anti-closed
source, anti-commercial[1] sample.)

This seems like it might be a relevant consideration to me.

when things break w/Gentoo, our devs/users tend to file bugs.

Fallen tree fallacy.

When the entry in the bug tracker (in a forest of bug trackers) is not
filled out, does the bug exist?

if Gentoo blowing away your rinky dinky config.sub hack breaks your project,
then take it as a sign that You're Doing It Wrong :).

Quite possibly. Truly, I agree.

But now go ask Stefano Lattarini how well-intentioned changes, made to
the behavior of the autotools without a gradual phase-in period over
years affect real world user reaction to those changes.

I *still* run across autoconfiscated packages using "configure.in",
despite years of warnings from Autoconf. I've even sent off bug reports
to those packages about it, and the obsolete name remains in their
source repo to this day. When autoconf stops recognizing configure.in,
I fully expect to hear wails, "Why did you break this?"

This idea isn't entirely bad. It's attempting to fix a real problem.
There's another problem pressing up against it from the other direction,
though: an implicit promise built up over decades of the Autotools'
existence that certain behaviors are allowed. When the rules change
without warning, people get upset.

And no, this thread doesn't count as fair warning. The vast majority of
autotools users don't read this list, and likely couldn't find this
thread in Google if they had a problem that this thread explained. What
those users see is that their OS of choice upgrades the autotools, and
"suddenly" the rules have changed.

-----
[1] When I characterize Gentoo as anti-commercial, I simply mean that
the distro proper does not contain paid commercial software, to my
knowledge. The closed, secretive mindset behind such software must
result in some differences in software development practice from that
used by open source, so you cannot extend your knowledge from open
source software to predict how closed source software development works.

[Mike Frysinger]

Post by Warren Young

we've got pretty good coverage for anything passably relevant (and then some).

So, because Gentoo has N text editors in the repo, the N+1th text editor
must port to Gentoo without problems?
You're committing a logical fallacy here, hasty generalization. "All
things in class A have property B, hence all things have property B."

how about you focus on the things i've actually said rather than making up
things and attributing them to me. i've chopped a couple of sections of your
e-mail as they were largely redundant.

Post by Warren Young
You propose changing the way autoconf works based on a sampling of
projects using it. A large sampling to be sure, but probably not
anywhere near a majority of those using autotools.

so you're proposing we never make a change because we haven't located and
tested every single project ever conceived w/autotools ? obviously that is
literally impossible and any such proposal is the exact antithesis to
progress.

in order to make a change, you need to weigh real world impact which means you
need samples. the samples stated by the various distros (arguably the largest
builders of source code) are significantly strong data points to indicate that
this is a dead feature.

Post by Warren Young
I *still* run across autoconfiscated packages using "configure.in",
despite years of warnings from Autoconf.

autoconf has never warned about it afaik. automake-1.12 was the first release
to complain, and that was released 24 Apr 2012 (just barely a year). which
means in order to see these warnings, people need to be running a recent
distro (checking ubuntu real quick shows it still doesn't have it), as well as
be using automake (some projects like to use just autoconf). which means
there are a good number of developers who aren't seeing the warning even
today.

so i don't know what you're referring to here.

Post by Warren Young
When autoconf stops recognizing configure.in,
I fully expect to hear wails, "Why did you break this?"

so what ? they'll rename things and move on.

Post by Warren Young
This idea isn't entirely bad. It's attempting to fix a real problem.
There's another problem pressing up against it from the other direction,
though: an implicit promise built up over decades of the Autotools'
existence that certain behaviors are allowed. When the rules change
without warning, people get upset.

a mere implementation detail

Post by Warren Young
And no, this thread doesn't count as fair warning.

i don't think anyone has considered "announced on mailing list" fair warning
for autotool packages. that is what NEWS is for as well as generated warnings
when you run them.

Post by Warren Young
[1] When I characterize Gentoo as anti-commercial, I simply mean that
the distro proper does not contain paid commercial software, to my
knowledge.

we have plenty of ebuilds in the main tree that install proprietary binary-
only packages. as in, you need to buy/license the package before you even get
a chance to install it. i'm also aware of companies who use Gentoo to
build/maintain their internal proprietary packages which either never get
released externally, or only done so as binary packages. so i guess your
characterization is inaccurate.

Post by Warren Young
The closed, secretive mindset behind such software must
result in some differences in software development practice from that
used by open source, so you cannot extend your knowledge from open
source software to predict how closed source software development works.

i've worked on closed sourced projects (both internal-only and released to the
world) at various companies in the past, as well as supported other companies
writing closed source software. there's no generalization you can make to
cover them all, although "stupidity" is frequently a common theme.
-mike

[Thomas Petazzoni]

Hello,

Post by Mike Frysinger
yes, Gentoo fixed this for every package in our tree like 9 years ago
(we added a common function like 11 years ago that ebuilds could call
manually, but we found that didn't scale). when you run a standard
autoconf script, we automatically search for files named "config.sub"
and "config.guess" and replace them with the up-to-date host copy.
no checking or anything :). in hindsight, that seems like a bad
idea, but in practice, i think we have yet to find a package that
this doesn't actually work.

FWIW, we do the same thing in Buildroot (a tool that builds embedded
Linux systems from source, through cross-compilation). Never had any
problem doing so.

Best regards,

Thomas

[Russ Allbery]

Post by Thomas Petazzoni

Post by Mike Frysinger
yes, Gentoo fixed this for every package in our tree like 9 years ago
(we added a common function like 11 years ago that ebuilds could call
manually, but we found that didn't scale). when you run a standard
autoconf script, we automatically search for files named "config.sub"
and "config.guess" and replace them with the up-to-date host copy. no
checking or anything :). in hindsight, that seems like a bad idea, but
in practice, i think we have yet to find a package that this doesn't
actually work.

FWIW, we do the same thing in Buildroot (a tool that builds embedded
Linux systems from source, through cross-compilation). Never had any
problem doing so.

Debian is moving in that direction as well. We have two different package
helper tools that do this in different ways. As always with Debian,
though, we're not very centralized about practices, so it takes a while to
get this deployed consistently across the whole archive.

[Wookey]

Post by Thomas Petazzoni
Hello,

Post by Mike Frysinger
yes, Gentoo fixed this for every package in our tree like 9 years ago
(we added a common function like 11 years ago that ebuilds could call
manually, but we found that didn't scale). when you run a standard
autoconf script, we automatically search for files named "config.sub"
and "config.guess" and replace them with the up-to-date host copy.
no checking or anything :). in hindsight, that seems like a bad
idea, but in practice, i think we have yet to find a package that
this doesn't actually work.

FWIW, we do the same thing in Buildroot (a tool that builds embedded
Linux systems from source, through cross-compilation). Never had any
problem doing so.

Same story in OpenEmbedded.

Given the widespread positive experience with this process, at least
in Linux distros, can those who think that defaulting to using
'current' versions is a bad idea produce any examples of genuine
problems large enough to counter the fairly major issue of updating
hundreds of these files for new architectures. Perhaps there are
non-linux arches where lots of things would break?

There have been some theoretical or obscure issues brought up so far
in this thread, and some history, but I haven't seen much that looks
like a good enough reason not to default to use current unless
configured not to (which anyone shipping a 'special' config.sub/guess
can use.

Wookey

[Paul Wise]

Post by Thomas Petazzoni

Post by Mike Frysinger
yes, Gentoo fixed this for every package in our tree like 9 years ago

FWIW, we do the same thing in Buildroot

Yes, it is a very common hack in all of the distros.
It would be nice if that wasn't necessary in the first place though.

[Henrique de Moraes Holschuh]

Post by Paul Wise

Post by Thomas Petazzoni

Post by Mike Frysinger
yes, Gentoo fixed this for every package in our tree like 9 years ago

FWIW, we do the same thing in Buildroot

Yes, it is a very common hack in all of the distros.
It would be nice if that wasn't necessary in the first place though.

Yes. It would have been really useful if autofoo used whatever is in
/usr/share/misc, unless there is a config.sub.override or
config.guess.override file in the source directory (or even better,
something pointed to by environment variables), and deprecate
source-directory config.guess and config.sub.

[Warren Young]

Post by Henrique de Moraes Holschuh
It would have been really useful if autofoo used whatever is in
/usr/share/misc, unless there is a config.sub.override or
config.guess.override file

You're starting from an assumption that autotools are installed on all
systems where you would want to build an autoconfiscated package.

For example, on Cygwin and FreeBSD, a C compiler is optional, and
installing it doesn't drag in the autotools.

All you're supposed to need to build an autoconfiscated package are
sh(1), make(1), and the compiler for whatever language the package's
source code is in.

I think you have the seed of a good idea here, though.

What if configure behaves just like it currently does unless it sees
that config.{guess,sub}[.override] aren't present at all? It can then
go looking for default versions in the usual system locations.

OS package creation tools could offer a per-package flag in the
package's configuration (.spec, .ebuild, .cygport, debian/...) that
tells it it is safe to remove shipped config.{guess,sub} files from the
tarball when building the source package, and that it should autoreconf
the package to get a configure script and Makefile.in that's aware of
this new behavior. The idea here is that binary package building
workstations *can* be assumed to have autotools installed.

It would also be useful if generated configure scripts supported a
--no-local-guess flag which forces it to look for system versions even
if it finds them in the same directory as the configure script. That
way a tarball can *ship* with config.{guess,sub}, but when a package
maintainer knows the system versions are going to work better, it can
pass that flag without autoreconf'ing the package.

You might think that unnecessarily fiddly, but it's based on an
experience of mine just last month. I was trying to build something
that shipped with outdated config.{guess,sub} files, but I couldn't
autoreconf it because its configure.ac file was *also* written in a
style so obsolescent that autoconf refused to cope with it. The package
creation tool "helpfully" tried overwriting config.{guess,sub} but it
did so with versions that were still too old, so even if I overwrote
them ahead of time, it clobbered my fixes.

That "--no-local-guess" flag would have saved me some aggravation.

Yes, I realize such behavior won't save me for another 3+ years, if I
have my way. I'd rather have these features painlessly in the future
than break a hundred thousand tarballs so I can have these features now.

[Paul Wise]

Post by Henrique de Moraes Holschuh
Yes. It would have been really useful if autofoo used whatever is in
/usr/share/misc, unless there is a config.sub.override or
config.guess.override file in the source directory (or even better,
something pointed to by environment variables), and deprecate
source-directory config.guess and config.sub.

My original patch didn't allow overrides, here is an updated one.

[Henrique de Moraes Holschuh]

Post by Paul Wise

Post by Henrique de Moraes Holschuh
Yes. It would have been really useful if autofoo used whatever is in
/usr/share/misc, unless there is a config.sub.override or
config.guess.override file in the source directory (or even better,
something pointed to by environment variables), and deprecate
source-directory config.guess and config.sub.

My original patch didn't allow overrides, here is an updated one.

IME, it is much better when any override mechanism make use of environment
variables. These are very easy to set per-build, per-user and system-wide,
unlike system-wide files and even per-project files.

It would be enough for the environment variables, when present, set the name
of the override files, and default to local config.{sub,guess}.override or
whatever when the variables are not set.

[Pavel Raiskup]

Post by Henrique de Moraes Holschuh
IME, it is much better when any override mechanism make use of
environment variables.

Yes, it was mentioned multiple times in this thread already and it was
always forgotten. Please consider this approach.

One thing was not mentioned here - if there was a CONFIG_GUESS/CONFIG_SUB
environment variables, what would be the consequences of having it solved
directly in config.{guess,sub} files?
I mean, if there was defined CONFIG_GUESS environment variable, the
config.guess could try to call 'config.guess' file somewhere in $PATH?

pros: we are able to easily patch also old packages (no-need to
autoreconfigure)

Pavel

[Paul Wise]

Post by Pavel Raiskup
Yes, it was mentioned multiple times in this thread already and it was
always forgotten. Please consider this approach.

The patches I've posted include environment variables too.

Post by Pavel Raiskup
One thing was not mentioned here - if there was a CONFIG_GUESS/CONFIG_SUB
environment variables, what would be the consequences of having it solved
directly in config.{guess,sub} files?

Both versions of the patch I posted for autoconf used these variables.

Post by Pavel Raiskup
I mean, if there was defined CONFIG_GUESS environment variable, the
config.guess could try to call 'config.guess' file somewhere in $PATH?

Modifying the config.guess/sub files to call other versions of
themselves was rejected by the maintainers a long time ago. My first
patch was for config.guess/sub to search the system for the latest
version and run it. That was rejected. The current approach is to change
the code that runs config.guess/sub so that it finds the latest
available version and runs it, with the possibility to override, mainly
for folks developing new ports.

Post by Pavel Raiskup
pros: we are able to easily patch also old packages (no-need to
autoreconfigure)

There would still be a long bootstrap period where old tarballs would
not have any way of running a modern config.sub/guess other than copying
them in from the system versions.

This is a fundamental problem of autotools, it comes from the days when
the system was probably a proprietary, old and buggy UNIX but we now
live in the days of fairly good and up-to-date Linux distributions where
we build software that wasn't necessarily autoreconfed with the latest
version of autotools. We need it to move to a hybrid model; use the
system version of everything unless it is old or missing.

[Pavel Raiskup]

Post by Paul Wise

Post by Pavel Raiskup
pros: we are able to easily patch also old packages (no-need to
autoreconfigure)

There would still be a long bootstrap period where old tarballs would
not have any way of running a modern config.sub/guess other than copying
them in from the system versions.

I meant that you are able to patch the very small part of
config.guess/config.sub with checking for environmental variables and
thats all -> you don't have to touch this package in future. The patched
config.sub is able to call system's one. No need to bootstrap.

Post by Paul Wise
Modifying the config.guess/sub files to call other versions of
themselves was rejected by the maintainers a long time ago.

Was there considered environmental variable approach?

Pavel

[Paul Wise]

Post by Pavel Raiskup
I meant that you are able to patch the very small part of
config.guess/config.sub with checking for environmental variables and
thats all -> you don't have to touch this package in future. The patched
config.sub is able to call system's one. No need to bootstrap.

There are thousands of copies of config.guess/sub (or configure scripts)
out there (in tarballs) with no support for this at all. Once it is
added to config.guess/sub in git (or autoconf) then it will take many
years before the majority of copies of config.guess/sub (or configure
scripts) have support for this. This is what I mean by bootstrap phase.

[Ben Elliston]

Post by Paul Wise
There are thousands of copies of config.guess/sub (or configure
scripts) out there (in tarballs) with no support for this at
all. Once it is added to config.guess/sub in git (or autoconf) then
it will take many years before the majority of copies of
config.guess/sub (or configure scripts) have support for this. This
is what I mean by bootstrap phase.

Right. Just thinking out loud: isn't the Autoconf concept of "aux
dir" of use here? That's where configure looks for config.guess.

The latest version of install-sh, config.guess, etc. could live in
such a system-wide directory. Unfortunately, it's not possible to set
auxdir from the configure command line as you can with --srcdir, etc.

Ben

[Ben Elliston]

When it comes to people building distro packages, here is another idea
thinking out loud. What's wrong with ..

$ find /tree/of/src/trees -name config.guess -exec ln -sf /etc/config.guess {} \;

This puts the latest version into the tree, no patching required.

Ben

[Ben Elliston]

People forgetting about the symlink during distribution of their
package. Not all systems support it. Using cp -f would be better.

OK, fine. :-)

I think there are a few different use cases people have in mind. My
understanding of the issue is that people responsible building large
numbers of autoconfiscated packages for distros (eg, Debian) are the
ones with the real headaches.

I tend to use a sub module repository and have config.guess and
config.sub in a directory (build-aux/) and I tell autoconf via
configure.ac where to find it.

Yes, but that requires re-running autoconf. I think we're trying to
avoid that because if configure.in is old, you may have a lot of work
to do to get autoreconf to work.

Ben

[Ben Elliston]

if [[ -f /usr/local/share/config/config.guess ]]
then
. /usr/local/share/config/config.guess
exit
fi

First, this does not solve the problem because it requires that every
package get a new version of config.guess. We're trying to overcome
having to modify every package. Second, I don't like the idea of
doing things that surprise users. That will confuse people.

Cheers, Ben

[Earnie Boyd]

Post by Ben Elliston
First, this does not solve the problem because it requires that every
package get a new version of config.guess. We're trying to overcome
having to modify every package.

So that's your objection to the symlink/copy idea as well?

Post by Ben Elliston
Second, I don't like the idea of doing things that surprise users. That will
confuse people.

It also causes recursiveness so the idea is lame unless we also trap
the recursive nature to one instance. I don't think it is that
confusing but perhaps --with-config-dir=/path/to/config files might be
nice and configure would execute the config.guess and config.sub in
that directory or error if the files do not exist or are unreadable.

[Ben Elliston]

Post by Earnie Boyd

Post by Ben Elliston
First, this does not solve the problem because it requires that every
package get a new version of config.guess. We're trying to overcome
having to modify every package.

So that's your objection to the symlink/copy idea as well?

No .. I don't have any objection to that. It's a rather unobtrusive
way and will work with every package, regardless of vintage.

Ben

[Earnie Boyd]

Post by Ben Elliston
Yes, but that requires re-running autoconf. I think we're trying to
avoid that because if configure.in is old, you may have a lot of work
to do to get autoreconf to work.

So in that case, a change to the start of config.guess and config.sub
something similar to the following might be best?

~~~~~
if [[ -f /usr/local/share/config/config.guess ]]
then
. /usr/local/share/config/config.guess
exit
fi

if [[ -f /usr/share/config/config.guess ]]
then
. /usr/share/config/config.guess
exit
fi
~~~~

[Eric Blake]

Post by Earnie Boyd

Post by Ben Elliston
Yes, but that requires re-running autoconf. I think we're trying to
avoid that because if configure.in is old, you may have a lot of work
to do to get autoreconf to work.

So in that case, a change to the start of config.guess and config.sub
something similar to the following might be best?
~~~~~
if [[ -f /usr/local/share/config/config.guess ]]
then
. /usr/local/share/config/config.guess
exit
fi
if [[ -f /usr/share/config/config.guess ]]
then
. /usr/share/config/config.guess
exit
fi

That would be fine with me, if you can get the upstream config project
to agree to it, since it would not require autoconf to do anything more
than recognize an environment variable. But are these scripts really
source-able, or should you be directly executing them? And does it have
proper avoidance of infinite loop if such a version of config.guess is
installed into /usr/local/share/config/config.guess?

[Earnie Boyd]

Post by Ben Elliston
When it comes to people building distro packages, here is another idea
thinking out loud. What's wrong with ..
$ find /tree/of/src/trees -name config.guess -exec ln -sf /etc/config.guess {} \;

People forgetting about the symlink during distribution of their
package. Not all systems support it. Using cp -f would be better.

Post by Ben Elliston
This puts the latest version into the tree, no patching required.

I tend to use a sub module repository and have config.guess and
config.sub in a directory (build-aux/) and I tell autoconf via
configure.ac where to find it.

[Earnie Boyd]

Post by Ben Elliston

Post by Paul Wise
There are thousands of copies of config.guess/sub (or configure
scripts) out there (in tarballs) with no support for this at
all. Once it is added to config.guess/sub in git (or autoconf) then
it will take many years before the majority of copies of
config.guess/sub (or configure scripts) have support for this. This
is what I mean by bootstrap phase.

Right. Just thinking out loud: isn't the Autoconf concept of "aux
dir" of use here? That's where configure looks for config.guess.
The latest version of install-sh, config.guess, etc. could live in
such a system-wide directory. Unfortunately, it's not possible to set
auxdir from the configure command line as you can with --srcdir, etc.

Maybe have a common directory of /usr/[local/]share/autoconf/auxdir
and teach autoconf to look there if it doesn't find
config.guess/config.sub in the project directory and copy them when
copy is specified? I dislike the environment variable idea. Too
fragile, someone forgets it is set and then has trouble because the
config.guess/config.sub he's trying to use isn't being used. I know
you mean for the variable to be set at autoreconf/configure usage but
there are always idiots who install it into their .profile files and
forget they did that.

[Eric Blake]

Post by Earnie Boyd
Maybe have a common directory of /usr/[local/]share/autoconf/auxdir
and teach autoconf to look there if it doesn't find
config.guess/config.sub in the project directory and copy them when
copy is specified? I dislike the environment variable idea. Too
fragile, someone forgets it is set and then has trouble because the
config.guess/config.sub he's trying to use isn't being used. I know
you mean for the variable to be set at autoreconf/configure usage but
there are always idiots who install it into their .profile files and
forget they did that.

Sorry, but this is the autoconf maintainer speaking:

I much prefer the environment variable approach. It is the same as we
do for other tools, such as $CC or $GREP. Users already have to be
aware of environment variables they have set; furthermore, we can mark
such variables as precious so that config.log records what was used.

Quit trying to overengineer a path search - all I am willing to commit
into autoconf is an environment variable override.

[Henrique de Moraes Holschuh]

Post by Pavel Raiskup

Post by Henrique de Moraes Holschuh
IME, it is much better when any override mechanism make use of
environment variables.

Yes, it was mentioned multiple times in this thread already and it was
always forgotten. Please consider this approach.
One thing was not mentioned here - if there was a CONFIG_GUESS/CONFIG_SUB
environment variables, what would be the consequences of having it solved
directly in config.{guess,sub} files?
I mean, if there was defined CONFIG_GUESS environment variable, the
config.guess could try to call 'config.guess' file somewhere in $PATH?
pros: we are able to easily patch also old packages (no-need to
autoreconfigure)

Works for me. But we [distros] do want to mandate autoreconf anyway in the
general case: it is the *only* way to keep upstream honest about the much
hated build system not bitrotting until it decides to blow up right when we
need it for a security update.

[Pavel Raiskup]

Post by Henrique de Moraes Holschuh
Works for me. But we [distros] do want to mandate autoreconf anyway in the
general case: it is the *only* way to keep upstream honest about the much
hated build system not bitrotting until it decides to blow up right when we
need it for a security update.

I know. But there is a lot of tarballs not able to be easily
autoreconf-ed (more than 10 years old) and not having upstream.. and it
needs a lot of changes downstream before autoreconf successes.. (and you
need to have a quite good knowledge about auto-toolset).

I'm glad to see that problem is approaching even solution requiring
autoconf .. not forcing anybody, just wanted to make sure that this was
also considered (and also that config-patches mailing list is also CC'd).

[Jan Engelhardt]

Post by Pavel Raiskup

Post by Henrique de Moraes Holschuh
Works for me. But we [distros] do want to mandate autoreconf anyway in the
general case: it is the *only* way to keep upstream honest about the much
hated build system not bitrotting until it decides to blow up right when we
need it for a security update.

I know. But there is a lot of tarballs not able to be easily
autoreconf-ed (more than 10 years old) and not having upstream.. and it
needs a lot of changes downstream before autoreconf successes.. (and you
need to have a quite good knowledge about auto-toolset).

If upstream is dead, the distros should perhaps reevaluate whether to
drop the package or de facto become upstream by a process of adoption.

[Pavel Raiskup]

Post by Jan Engelhardt

Post by Pavel Raiskup

Post by Henrique de Moraes Holschuh
Works for me. But we [distros] do want to mandate autoreconf anyway in the
general case: it is the *only* way to keep upstream honest about the much
hated build system not bitrotting until it decides to blow up right when we
need it for a security update.

I know. But there is a lot of tarballs not able to be easily
autoreconf-ed (more than 10 years old) and not having upstream.. and it
needs a lot of changes downstream before autoreconf successes.. (and you
need to have a quite good knowledge about auto-toolset).

If upstream is dead, the distros should perhaps reevaluate whether to
drop the package or de facto become upstream by a process of adoption.

Yes. But if the problem is as easy as outdated config.{guess,sub}, simply
setting the CONFIG_{GUESS,SUB} variable is far more suitable. Sometimes
distros are deploying compat packages having outdated sources.

What about this? Ben (and others), would you consider something similar
like this one? Without PATH traversal it could be very trivial:

diff --git a/config.sub b/config.sub
index 8b612ab..daac889 100755
--- a/config.sub
+++ b/config.sub
@@ -50,6 +50,12 @@ timestamp='2013-04-24'
# CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM
# It is wrong to echo any other type of specification.

+if test -n "$CONFIG_SUB"; then
+ # clean CONFIG_SUB variable!
+ CONFIG_SUB= $CONFIG_SUB $1
+ exit
+fi
+
me=`echo "$0" | sed -e 's,.*/,,'`

usage="\

[Ben Elliston]

I suggested a simple, low impact way of updating the files,
particularly for people wanting to build a large number of packages
(eg, for a distro). Can anyone tell me why this approach is not
satisfactory?

Ben

[Earnie Boyd]

Post by Ben Elliston
I suggested a simple, low impact way of updating the files,
particularly for people wanting to build a large number of packages
(eg, for a distro). Can anyone tell me why this approach is not
satisfactory?

It's what I've done for years. Does it get rid of the problem? I
don't think so but for legacy code that is no longer being maintained,
either you maintain it, or the problem exists into infinity with a
hard stop when someone does maintain it. I think the battle is trying
to overcome continuing the legacy method of needing to replace
config.guess/config.sub within a package and allow a common (or
configurable) location be used as new development takes place. Your
symlink/copy method doesn't overcome that legacy method so it would
not be a satisfactory solution since that solution continues the
legacy method. However, your solution does help those with packages
that currently use that legacy method.

[Pavel Raiskup]

It's what I've done for years. Does it get rid of the problem? I don't
think so but for legacy code that is no longer being maintained, either
you maintain it, or the problem exists into infinity with a hard stop
when someone does maintain it. I think the battle is trying to overcome
continuing the legacy method of needing to replace
config.guess/config.sub within a package and allow a common (or
configurable) location be used as new development takes place.

The http://lists.gnu.org/archive/html/autoconf/2013-05/msg00069.html is
probably what you are talking about. I like this idea too, but these two
ideas are not overlapping, IMO.

Maybe have a common directory of /usr/[local/]share/autoconf/auxdir and
teach autoconf to look there if it doesn't find

Even if we were able to "teach" in future our ./configure scripts (not
autoconf — as autoreconf -vfi actually solves this even now by calling
automake) to look into some configurable place using special option, the
ENV VAR solution _may still co-exist_ (and should have always the highest
priority).

Pavel

[Mike Frysinger]

Post by Jan Engelhardt

Post by Pavel Raiskup

Post by Henrique de Moraes Holschuh
Works for me. But we [distros] do want to mandate autoreconf anyway in
the general case: it is the *only* way to keep upstream honest about
the much hated build system not bitrotting until it decides to blow up
right when we need it for a security update.

I know. But there is a lot of tarballs not able to be easily
autoreconf-ed (more than 10 years old) and not having upstream.. and it
needs a lot of changes downstream before autoreconf successes.. (and you
need to have a quite good knowledge about auto-toolset).

If upstream is dead, the distros should perhaps reevaluate whether to
drop the package or de facto become upstream by a process of adoption.

that's might sound great, but really doesn't line up with reality. distros
are chronically understaffed and becoming defacto upstreams for every random
package that goes dormant/dead and can't survive an `autoreconf` isn't viable.
-mike

[Eric Blake]

Post by Paul Wise

Post by Henrique de Moraes Holschuh
Yes. It would have been really useful if autofoo used whatever is in
/usr/share/misc, unless there is a config.sub.override or
config.guess.override file in the source directory (or even better,
something pointed to by environment variables), and deprecate
source-directory config.guess and config.sub.

My original patch didn't allow overrides, here is an updated one.

I would MUCH rather see us honor a CONFIG_GUESS and CONFIG_SUB
environment variable, rather than baking in a PATH search. This topic
has come up in the past, where I made the same request back then.

[Paul Wise]

Post by Eric Blake
I would MUCH rather see us honor a CONFIG_GUESS and CONFIG_SUB
environment variable, rather than baking in a PATH search. This topic
has come up in the past, where I made the same request back then.

The patch does both and both are needed AFAICT.

[Eric Blake]

Post by Paul Wise

Post by Eric Blake
I would MUCH rather see us honor a CONFIG_GUESS and CONFIG_SUB
environment variable, rather than baking in a PATH search. This topic
has come up in the past, where I made the same request back then.

The patch does both and both are needed AFAICT.

I disagree. Env-var override should be sufficient, without needing any
PATH probing.

[Paul Smith]

Post by Eric Blake

Post by Paul Wise

Post by Eric Blake
I would MUCH rather see us honor a CONFIG_GUESS and CONFIG_SUB
environment variable, rather than baking in a PATH search. This topic
has come up in the past, where I made the same request back then.

The patch does both and both are needed AFAICT.

I disagree. Env-var override should be sufficient, without needing any
PATH probing.

FWIW I agree with Eric. Having behind-the-scenes path probing for local
overrides is, IMO, asking for a lot of trouble. It's far to easy to
drop a file on your system and forget about it it, leading to much
confusion and frustration a few months/years later. Also consider the
support burden...

I just don't see the need for it.

[Wookey]

Post by Eric Blake

Post by Paul Wise

Post by Eric Blake
I would MUCH rather see us honor a CONFIG_GUESS and CONFIG_SUB
environment variable, rather than baking in a PATH search. This topic
has come up in the past, where I made the same request back then.

The patch does both and both are needed AFAICT.

I disagree. Env-var override should be sufficient, without needing any
PATH probing.

The problem with this in the context of distro buildds was explained
in this sub-part of the thread from Oct last year:
http://article.gmane.org/gmane.comp.sysutils.autoconf.general/14756

ENV VARS are carefully filtered out of buildd environments in order to
get clean builds. We really want a mechanism where the distro default
build just looks in the right (system) place, unless you ask for
something different.

Now it probably is possible to get this ENV VAR set in buildd
environments, but what if the cmake, maven, ant, scons and $everybody
else also insist on the same mechanism for default builds to work
properly? That's a lot of ENV VARS - it doesn't scale well. And if
someone does a local build outside the buildd environment now they
have to remember to set these variables too, otherwise suddenly stuff
that built on the buildds doesn't build for them.

ENV VARS are very useful for all sorts of things, but they are
problematic for distro build defaults, so there is a good reason for
the path walk.

Now we could patch autoconf in Debian (and other distros patch it too)
to deal with this, but the whole point of this excercise is to fix this
upstream so that over time the problem will just fade into history.

Wookey

[Eric Blake]

Post by Wookey

Post by Eric Blake

Post by Paul Wise

Post by Eric Blake
I would MUCH rather see us honor a CONFIG_GUESS and CONFIG_SUB
environment variable, rather than baking in a PATH search. This topic
has come up in the past, where I made the same request back then.

The patch does both and both are needed AFAICT.

I disagree. Env-var override should be sufficient, without needing any
PATH probing.

The problem with this in the context of distro buildds was explained
http://article.gmane.org/gmane.comp.sysutils.autoconf.general/14756
ENV VARS are carefully filtered out of buildd environments in order to
get clean builds. We really want a mechanism where the distro default
build just looks in the right (system) place, unless you ask for
something different.

The distro default build system should SET such an env-var. Problem
solved, no path search needed. Clean builds are a product of using the
same environment, and that can include SETTING useful variables, rather
than scrubbing them.

[Mike Frysinger]

Post by Eric Blake

Post by Paul Wise

Post by Henrique de Moraes Holschuh
Yes. It would have been really useful if autofoo used whatever is in
/usr/share/misc, unless there is a config.sub.override or
config.guess.override file in the source directory (or even better,
something pointed to by environment variables), and deprecate
source-directory config.guess and config.sub.

My original patch didn't allow overrides, here is an updated one.

I would MUCH rather see us honor a CONFIG_GUESS and CONFIG_SUB
environment variable, rather than baking in a PATH search. This topic
has come up in the past, where I made the same request back then.

this might be sufficient for distro packagers (once they're "in the know" that
they have to export these two), but that doesn't help people who download
arbitrary packages and run `./configure` themselves.

what if the autoconf macros grew a new option/macro so that in the very
uncommon case that someone has written their own, they could explicitly
declare so ?
AC_CANONICAL_CUSTOM

this would disable the custom search path and only respect the env vars
-mike

[Eric Blake]

Post by Mike Frysinger

Post by Eric Blake
I would MUCH rather see us honor a CONFIG_GUESS and CONFIG_SUB
environment variable, rather than baking in a PATH search. This topic
has come up in the past, where I made the same request back then.

this might be sufficient for distro packagers (once they're "in the know" that
they have to export these two), but that doesn't help people who download
arbitrary packages and run `./configure` themselves.
what if the autoconf macros grew a new option/macro so that in the very
uncommon case that someone has written their own, they could explicitly
declare so ?
AC_CANONICAL_CUSTOM
this would disable the custom search path and only respect the env vars

I still don't see why you are overengineering things. Make the env-var
precious - then it will show up in ./configure --help output, and be
preserved so that ./config.status --config will show you what it was set
to at the time. If the only way to get the override is via an env-var,
then there is no need for the complexity of either a baked-in path
search nor a means of letting SOME packages disable the complexity of a
baked-in path search. If you can argue that SOME packages will want to
disable the complexity, then I can argue that we should make the default
of disabled complexity be everywhere.

[Mike Frysinger]

Post by Eric Blake

Post by Mike Frysinger

Post by Eric Blake
I would MUCH rather see us honor a CONFIG_GUESS and CONFIG_SUB
environment variable, rather than baking in a PATH search. This topic
has come up in the past, where I made the same request back then.

this might be sufficient for distro packagers (once they're "in the know"
that they have to export these two), but that doesn't help people who
download arbitrary packages and run `./configure` themselves.
what if the autoconf macros grew a new option/macro so that in the very
uncommon case that someone has written their own, they could explicitly
declare so ?
AC_CANONICAL_CUSTOM
this would disable the custom search path and only respect the env vars

I still don't see why you are overengineering things. Make the env-var
precious - then it will show up in ./configure --help output, and be
preserved so that ./config.status --config will show you what it was set
to at the time. If the only way to get the override is via an env-var,
then there is no need for the complexity of either a baked-in path
search nor a means of letting SOME packages disable the complexity of a
baked-in path search. If you can argue that SOME packages will want to
disable the complexity, then I can argue that we should make the default
of disabled complexity be everywhere.

i don't have a problem throwing out support for custom config.{guess,sub} files.
as noted elsewhere in this thread, i believe that to be an obsolete art.

my point for keeping the automatic search behavior is so that people don't
have to pour through --help output and set yet-more esoteric variables so
things "just work". you're of course right that by having two variables
results in dirt simple code on the implementation side. but the end user
experience is terrible. however, adding a patch search, while is "more" code,
is not complicated, and both the end user and distros win.

the code could even be made simpler if we throw out the --time-stamp check and
accept things based purely on their name. simply leverage AC_PATH_PROG.
-mike

[Eric Blake]

Post by Mike Frysinger
my point for keeping the automatic search behavior is so that people don't
have to pour through --help output and set yet-more esoteric variables so
things "just work". you're of course right that by having two variables
results in dirt simple code on the implementation side. but the end user
experience is terrible. however, adding a patch search, while is "more" code,
is not complicated, and both the end user and distros win.
the code could even be made simpler if we throw out the --time-stamp check and
accept things based purely on their name. simply leverage AC_PATH_PROG.

Maybe you have a point there. Basically, I'd like $CONFIG_GUESS to
behave like $CC, and maybe searching the user's PATH is worth trying
first, falling back to our in-tree version if a path search turns up
nothing, and where the env-var always takes precedence. I still don't
think we need to hard-code any additions to the user's path. After all,
the ONLY time that using a newer config.guess will help you is when
porting to a new machine type that was not present in an older
config.guess; but if you argue that the first thing a distro does when
preparing a port to a new machine triple is to install an updated
/usr/bin/config.guess, then that will be sufficient to let all the other
new enough packages automatically find the right triple. Even if
/usr/bin/config.guess is older than the one bundled with an (even newer)
package, it is still new enough to support the target triple on which
you are compiling that package. So favoring a PATH lookup over the
in-tree version should always work, and falling back to the in-tree
version instead of outright failing should work for all situations where
config.guess is not installed on the user's PATH.

[Mike Frysinger]

Post by Eric Blake

Post by Mike Frysinger
my point for keeping the automatic search behavior is so that people
don't have to pour through --help output and set yet-more esoteric
variables so things "just work". you're of course right that by having
two variables results in dirt simple code on the implementation side.
but the end user experience is terrible. however, adding a patch
search, while is "more" code, is not complicated, and both the end user
and distros win.
the code could even be made simpler if we throw out the --time-stamp
check and accept things based purely on their name. simply leverage
AC_PATH_PROG.

Maybe you have a point there. Basically, I'd like $CONFIG_GUESS to
behave like $CC, and maybe searching the user's PATH is worth trying
first, falling back to our in-tree version if a path search turns up
nothing, and where the env-var always takes precedence. I still don't
think we need to hard-code any additions to the user's path. After all,
the ONLY time that using a newer config.guess will help you is when
porting to a new machine type that was not present in an older
config.guess; but if you argue that the first thing a distro does when
preparing a port to a new machine triple is to install an updated
/usr/bin/config.guess, then that will be sufficient to let all the other
new enough packages automatically find the right triple. Even if
/usr/bin/config.guess is older than the one bundled with an (even newer)
package, it is still new enough to support the target triple on which
you are compiling that package. So favoring a PATH lookup over the
in-tree version should always work, and falling back to the in-tree
version instead of outright failing should work for all situations where
config.guess is not installed on the user's PATH.

i don't think anyone installs these things into $PATH today. we put them into
/usr/share/ somewhere. the idea with the custom path search was so that you
didn't need to be running a good distro for this stuff to work ... it would
work with any system that follows default libtool/automake install
conventions.

i misread the patch and what it was doing with --timestamp. the point was to
make sure it didn't inadvertently select an older version. so i guess i'm in
favor of the current (more complicated) version :/.

the automake-1.12+ has a --print-libdir option. what if we use that rather
than hardcoding the automake paths ?

if we're all in agreement with the $CONFIG_SUB / $CONFIG_GUESS starting point,
maybe we merge that now and continue debating the extended points ?
-mike

[Mike Frysinger]

Post by Paul Wise

Post by Henrique de Moraes Holschuh
Yes. It would have been really useful if autofoo used whatever is in
/usr/share/misc, unless there is a config.sub.override or
config.guess.override file in the source directory (or even better,
something pointed to by environment variables), and deprecate
source-directory config.guess and config.sub.

My original patch didn't allow overrides, here is an updated one.
+AC_DEFUN([AC_CONFIG_AUX_DIR,

pretty sure you're missing a closing ] there

Post by Paul Wise
+ /usr/share/gnuconfig \

if you post another revision, just delete this path. i think Gentoo is the
only one that uses this, and one of the other paths will catch us.
-mike