Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Mon, 2013-05-20 at 08:37 -0600, Eric Blake wrote: > 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. -- bye, pabs http://bonedaddy.net/pabs3/ signature.asc Description: This is a digitally signed message part ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Mon, 2013-05-20 at 08:43 +0200, Pavel Raiskup wrote: > 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. -- bye, pabs http://bonedaddy.net/pabs3/ signature.asc Description: This is a digitally signed message part ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Mon, 2013-05-20 at 07:40 +0200, Pavel Raiskup wrote:
> 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.
> 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.
> 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.
> 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.
--
bye,
pabs
http://bonedaddy.net/pabs3/
signature.asc
Description: This is a digitally signed message part
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Fri, 2013-05-17 at 16:05 -0300, Henrique de Moraes Holschuh wrote:
> 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.
--
bye,
pabs
http://bonedaddy.net/pabs3/
From 17afa8e123997e21e55755cfaaae07b5f84de690 Mon Sep 17 00:00:00 2001
From: Paul Wise
Date: Tue, 9 Oct 2012 11:06:37 +0800
Subject: [PATCH] Check a number of paths for newer config.guess/config.sub,
run the latest.
This helps people who are bootstrapping new systems from existing software
that uses GNU autotools, config.guess and config.sub.
This is very useful for distributions like Debian that add new architectures
and then have to update config.sub and config.guess in every single package
that uses automake or have to workaround the problem by adding code to each
package to copy in the latest versions of these scripts from another package
containing the latest version of the scripts (autotools-dev in Debian).
Allow software authors and distro porters to override the latest version.
---
lib/autoconf/general.m4 | 72 ++---
1 file changed, 56 insertions(+), 16 deletions(-)
diff --git a/lib/autoconf/general.m4 b/lib/autoconf/general.m4
index 70b0168..f746b73 100644
--- a/lib/autoconf/general.m4
+++ b/lib/autoconf/general.m4
@@ -1680,6 +1680,51 @@ AC_DEFUN([AC_CONFIG_AUX_DIR],
AC_DEFUN([AC_CONFIG_AUX_DIR_DEFAULT],
[AC_CONFIG_AUX_DIRS("$srcdir" "$srcdir/.." "$srcdir/../..")])
+# AC_CONFIG_AUX_DIR
+# -
+# Internal subroutine.
+# Find the latest version of config.guess and config.sub that is
+# available on the system to prevent issues with bootstrapping.
+# Allows explicitly overriding the latest one where needed.
+AC_DEFUN([AC_CONFIG_AUX_DIR,
+[
+for path in \
+ "$AUTOCONF_AUX_DIR" \
+ "$HOME/.config/autotools" \
+ "$2" \
+ ; do
+if test -x "$path/config.$1.override" ; then
+ ac_config_$1="$path/config.$1.override"
+fi
+done
+if test -z "$ac_config_$1" ; then
+ cur_v=0
+ for path in \
+"$AUTOCONF_AUX_DIR" \
+"$2" \
+"$HOME/.config/autotools" \
+/usr/local/share/automake-* \
+/usr/local/share/automake \
+/usr/local/share/libtool/config \
+/usr/share/misc \
+/usr/share/gnuconfig \
+/usr/share/automake-* \
+/usr/share/automake \
+/usr/share/libtool/config \
+"$[CONFIG_]m4_toupper([$1])" \
+; do
+ if test -x "$path/config.$1" ; then
+v=`$SHELL "$path/config.$1" --time-stamp | sed s/-//g`
+if test "$v" -gt "$cur_v" ; then
+ cur_v="$v"
+ latest="$path"
+fi
+ fi
+ done
+ ac_config_$1="$latest/config.$1"
+fi
+])# AC_CONFIG_AUX_DIR
+
# AC_CONFIG_AUX_DIRS(DIR ...)
# ---
@@ -1708,13 +1753,8 @@ if test -z "$ac_aux_dir"; then
AC_MSG_ERROR([cannot find install-sh, install.sh, or shtool in $1])
fi
-# These three variables are undocumented and unsupported,
-# and are intended to be withdrawn in a future Autoconf release.
-# They can cause serious problems if a builder's source tree is in a directory
-# whose full name contains unusual characters.
-ac_config_guess="$SHELL $ac_aux_dir/config.guess" # Please don't use this var.
-ac_config_sub="$SHELL $ac_aux_dir/config.sub" # Please don't use this var.
-ac_configure="$SHELL $ac_aux_dir/configure" # Please don't use this var.
+AC_CONFIG_AUX_DIR([guess],[$1])
+AC_CONFIG_AUX_DIR([sub],[$1])
AC_PROVIDE([AC_CONFIG_AUX_DIR_DEFAULT])dnl
])# AC_CONFIG_AUX_DIRS
@@ -1832,17 +1872,17 @@ m4_divert_once([HELP_CANON],
System types:
--build=BUILD configure for building on BUILD [guessed]]])dnl
# Make sure we can run config.sub.
-$SHELL "$ac_aux_dir/config.sub" sun4 >/dev/null 2>&1 ||
- AC_MSG_ERROR([cannot run $SHELL $ac_aux_dir/config.sub])
+$SHELL "$ac_config_sub" sun4 >/dev/null 2>&1 ||
+ AC_MSG_ERROR([cannot run $SHELL $ac_config_sub])
AC_CACHE_CHECK([build system type], [ac_cv_build],
[ac_build_alias=$build_alias
test "x$ac_build_alias" = x &&
- ac_build_alias=`$SHELL "$ac_aux_dir/config.guess"`
+ ac_build_alias=`$SHELL "$ac_config_guess"`
test "x$ac_build_alias" = x &&
AC_MSG_ERROR([cannot guess build type; you must specify one])
-ac_cv_build=`$SHELL "$ac_aux_dir/config.sub" $ac_build_alias` ||
- AC_MSG_ERROR([$SHELL $ac_aux_dir/config.sub $ac_build_alia
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Wed, 2013-05-15 at 16:30 +0200, Thomas Petazzoni wrote: > On Tue, 14 May 2013 23:53:44 -0400, Mike Frysinger wrote: > > 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. -- bye, pabs http://bonedaddy.net/pabs3/ signature.asc Description: This is a digitally signed message part ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] pass #2 at getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Tue, 2012-10-09 at 07:14 +0200, Ralf Corsepius wrote: > 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 -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. > 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. > 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_ 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. -- bye, pabs http://bonedaddy.net/pabs3/ signature.asc Description: This is a digitally signed message part ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] pass #2 at getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Mon, 2012-10-08 at 22:03 -0600, Eric Blake wrote:
> 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.
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.
--
bye,
pabs
http://bonedaddy.net/pabs3/
From 97029cdf7c526212ee4a470bbc47075aaefc6c4e Mon Sep 17 00:00:00 2001
From: Paul Wise
Date: Tue, 9 Oct 2012 11:06:37 +0800
Subject: [PATCH] Check a number of paths for newer config.guess/config.sub,
run the latest.
This helps people who are bootstrapping new systems from existing software
that uses GNU autotools, config.guess and config.sub.
This is very useful for distributions like Debian that add new architectures
and then have to update config.sub and config.guess in every single package
that uses automake or have to workaround the problem by adding code to each
package to copy in the latest versions of these scripts from another package
containing the latest version of the scripts (autotools-dev in Debian).
---
lib/autoconf/general.m4 | 59 ++-
1 file changed, 43 insertions(+), 16 deletions(-)
diff --git a/lib/autoconf/general.m4 b/lib/autoconf/general.m4
index 51cee30..6f26116 100644
--- a/lib/autoconf/general.m4
+++ b/lib/autoconf/general.m4
@@ -1680,6 +1680,38 @@ AC_DEFUN([AC_CONFIG_AUX_DIR],
AC_DEFUN([AC_CONFIG_AUX_DIR_DEFAULT],
[AC_CONFIG_AUX_DIRS("$srcdir" "$srcdir/.." "$srcdir/../..")])
+# AC_CONFIG_AUX_DIR_LATEST
+# -
+# Internal subroutine.
+# Find the latest version of config.guess and config.sub that is
+# available on the system to prevent issues with bootstrapping.
+AC_DEFUN([AC_CONFIG_AUX_DIR_LATEST],
+[
+cur_v=0
+for path in \
+ $2 \
+ "$HOME/.config/autotools" \
+ /usr/local/share/automake-* \
+ /usr/local/share/automake \
+ /usr/local/share/libtool/config \
+ /usr/share/misc \
+ /usr/share/gnuconfig \
+ /usr/share/automake-* \
+ /usr/share/automake \
+ /usr/share/libtool/config \
+ "$[CONFIG_]m4_toupper([$1])" \
+ ; do
+if test -x "$path/config.$1" ; then
+ v=`$SHELL "$path/config.$1" --time-stamp | sed s/-//g`
+ if test "$v" -gt "$cur_v" ; then
+cur_v="$v"
+latest="$path"
+ fi
+fi
+done
+ac_config_$1="$latest/config.$1"
+])# AC_CONFIG_AUX_DIR_LATEST
+
# AC_CONFIG_AUX_DIRS(DIR ...)
# ---
@@ -1708,13 +1740,8 @@ if test -z "$ac_aux_dir"; then
AC_MSG_ERROR([cannot find install-sh, install.sh, or shtool in $1])
fi
-# These three variables are undocumented and unsupported,
-# and are intended to be withdrawn in a future Autoconf release.
-# They can cause serious problems if a builder's source tree is in a directory
-# whose full name contains unusual characters.
-ac_config_guess="$SHELL $ac_aux_dir/config.guess" # Please don't use this var.
-ac_config_sub="$SHELL $ac_aux_dir/config.sub" # Please don't use this var.
-ac_configure="$SHELL $ac_aux_dir/configure" # Please don't use this var.
+AC_CONFIG_AUX_DIR_LATEST([guess],[$1])
+AC_CONFIG_AUX_DIR_LATEST([sub],[$1])
AC_PROVIDE([AC_CONFIG_AUX_DIR_DEFAULT])dnl
])# AC_CONFIG_AUX_DIRS
@@ -1796,17 +1823,17 @@ m4_divert_once([HELP_CANON],
System types:
--build=BUILD configure for building on BUILD [guessed]]])dnl
# Make sure we can run config.sub.
-$SHELL "$ac_aux_dir/config.sub" sun4 >/dev/null 2>&1 ||
- AC_MSG_ERROR([cannot run $SHELL $ac_aux_dir/config.sub])
+$SHELL "$ac_config_sub" sun4 >/dev/null 2>&1 ||
+ AC_MSG_ERROR([cannot run $SHELL $ac_config_sub])
AC_CACHE_CHECK([build system type], [ac_cv_build],
[ac_build_alias=$build_alias
test "x$ac_build_alias" = x &&
- ac_build_alias=`$SHELL "$ac_aux_dir/config.guess"`
+ ac_build_alias=`$SHELL "$ac_config_guess"`
test "x$ac_build_alias" = x &&
AC_MSG_ERROR([cannot guess build type; you must specify one])
-ac_cv_build=`$SHELL "$ac_aux_dir/config.sub" $ac_build_alias` ||
- AC_MSG_ERROR([$SHELL $ac_aux_dir/config.s
[RFC] pass #2 at getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Mon, 2012-10-08 at 20:46 +0800, Paul Wise wrote:
> 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.
--
bye,
pabs
http://bonedaddy.net/pabs3/
From daf894f36dd53c7b3033a727aef73a149c7030b3 Mon Sep 17 00:00:00 2001
From: Paul Wise
Date: Tue, 9 Oct 2012 11:06:37 +0800
Subject: [PATCH] Check a number of paths for newer config.guess/config.sub,
run the latest.
This helps people who are bootstrapping new systems from existing software
that uses GNU autotools, config.guess and config.sub.
This is very useful for distributions like Debian that add new architectures
and then have to update config.sub and config.guess in every single package
that uses automake or have to workaround the problem by adding code to each
package to copy in the latest versions of these scripts from another package
containing the latest version of the scripts (autotools-dev in Debian).
---
lib/autoconf/general.m4 | 57 ++-
1 file changed, 41 insertions(+), 16 deletions(-)
diff --git a/lib/autoconf/general.m4 b/lib/autoconf/general.m4
index 51cee30..116bf95 100644
--- a/lib/autoconf/general.m4
+++ b/lib/autoconf/general.m4
@@ -1680,6 +1680,36 @@ AC_DEFUN([AC_CONFIG_AUX_DIR],
AC_DEFUN([AC_CONFIG_AUX_DIR_DEFAULT],
[AC_CONFIG_AUX_DIRS("$srcdir" "$srcdir/.." "$srcdir/../..")])
+# AC_CONFIG_AUX_DIR_LATEST
+# -
+# Internal subroutine.
+# Find the latest version of config.guess and config.sub that is
+# available on the system to prevent issues with bootstrapping.
+AC_DEFUN([AC_CONFIG_AUX_DIR_LATEST],
+[
+cur_v=0
+for path in \
+ $2 \
+ "$HOME/.config/autotools" \
+ /usr/local/share/automake-* \
+ /usr/local/share/automake \
+ /usr/share/misc \
+ /usr/share/gnuconfig \
+ /usr/share/automake-* \
+ /usr/share/automake \
+ /usr/share/libtool/config \
+ ; do
+if test -x "$path/config.$1" ; then
+ v=`$SHELL "$path/config.$1" --time-stamp | sed s/-//g`
+ if test "$v" -gt "$cur_v" ; then
+cur_v="$v"
+latest="$path"
+ fi
+fi
+done
+ac_config_$1="$latest/config.$1"
+])# AC_CONFIG_AUX_DIR_LATEST
+
# AC_CONFIG_AUX_DIRS(DIR ...)
# ---
@@ -1708,13 +1738,8 @@ if test -z "$ac_aux_dir"; then
AC_MSG_ERROR([cannot find install-sh, install.sh, or shtool in $1])
fi
-# These three variables are undocumented and unsupported,
-# and are intended to be withdrawn in a future Autoconf release.
-# They can cause serious problems if a builder's source tree is in a directory
-# whose full name contains unusual characters.
-ac_config_guess="$SHELL $ac_aux_dir/config.guess" # Please don't use this var.
-ac_config_sub="$SHELL $ac_aux_dir/config.sub" # Please don't use this var.
-ac_configure="$SHELL $ac_aux_dir/configure" # Please don't use this var.
+AC_CONFIG_AUX_DIR_LATEST([guess],[$1])
+AC_CONFIG_AUX_DIR_LATEST([sub],[$1])
AC_PROVIDE([AC_CONFIG_AUX_DIR_DEFAULT])dnl
])# AC_CONFIG_AUX_DIRS
@@ -1796,17 +1821,17 @@ m4_divert_once([HELP_CANON],
System types:
--build=BUILD configure for building on BUILD [guessed]]])dnl
# Make sure we can run config.sub.
-$SHELL "$ac_aux_dir/config.sub" sun4 >/dev/null 2>&1 ||
- AC_MSG_ERROR([cannot run $SHELL $ac_aux_dir/config.sub])
+$SHELL "$ac_config_sub" sun4 >/dev/null 2>&1 ||
+ AC_MSG_ERROR([cannot run $SHELL $ac_config_sub])
AC_CACHE_CHECK([build system type], [ac_cv_build],
[ac_build_alias=$build_alias
test "x$ac_build_alias" = x &&
- ac_build_alias=`$SHELL "$ac_aux_dir/config.guess"`
+ ac_build_alias=`$SHELL "$ac_config_guess"`
test "x$ac_build_alias" = x &&
AC_MSG_ERROR([cannot guess build type; you must specify one])
-ac_cv_build=`$SHELL "$ac_aux_dir/config.sub" $ac_build_alias` ||
- AC_MSG_ERROR([$SHELL $ac_aux_dir/config.sub $ac_build_alias failed])
+ac_cv_build=`$SHELL "$ac_config_sub" $ac_build_alias` ||
+ AC_MSG_ERROR([$SHELL $ac_config_sub $ac_build_alias failed])
])
_AC_CANONICAL_SPLIT(build)
])# AC_CANONICAL_BUILD
@@ -1822,8 +1847,8 @@ AC_CACHE_CHECK([host system type], [ac_cv_host],
[if test "x$host_alias" = x; then
ac_cv_host
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Mon, 2012-10-08 at 13:52 -0500, Bob Friesenhahn wrote: > 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. > 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. > 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. > 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. -- bye, pabs http://bonedaddy.net/pabs3/ signature.asc Description: This is a digitally signed message part ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Mon, 2012-10-08 at 18:40 -0300, Henrique de Moraes Holschuh wrote:
> 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.
> 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!
> 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
--
bye,
pabs
http://bonedaddy.net/pabs3/
signature.asc
Description: This is a digitally signed message part
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Mon, 2012-10-08 at 12:26 -0700, Russ Allbery wrote: > Personally, I've already started converting every package I maintain that > uses Autoconf to using dh_autoreconf during the build. Likewise. > 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. > 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. > 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 -- bye, pabs http://bonedaddy.net/pabs3/ signature.asc Description: This is a digitally signed message part ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Mon, 2012-10-08 at 11:07 -0500, Bob Friesenhahn wrote: > 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. > 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. -- bye, pabs http://bonedaddy.net/pabs3/ signature.asc Description: This is a digitally signed message part ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Mon, 2012-10-08 at 10:22 -0600, Eric Blake wrote: > 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. > 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. > 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/ > 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. -- bye, pabs http://bonedaddy.net/pabs3/ signature.asc Description: This is a digitally signed message part ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
[RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
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 -- bye, pabs http://bonedaddy.net/pabs3/ From a8e1e438d4e529ba0a9d1f28b73eacb2d881071d Mon Sep 17 00:00:00 2001 From: Paul Wise Date: Mon, 8 Oct 2012 19:34:50 +0800 Subject: [PATCH] Check a number of paths for newer config.guess/config.sub and run the latest. This helps people who are bootstrapping new systems from existing software that uses GNU autotools, config.guess and config.sub. This is very useful for distributions like Debian that add new architectures and then have to update config.sub and config.guess in every single package that uses automake or have to workaround the problem by adding code to each package to copy in the latest versions of these scripts from another package containing the latest version of the scripts (autotools-dev in Debian). --- lib/autoconf/general.m4 | 34 ++ 1 file changed, 34 insertions(+) diff --git a/lib/autoconf/general.m4 b/lib/autoconf/general.m4 index 51cee30..d6366c9 100644 --- a/lib/autoconf/general.m4 +++ b/lib/autoconf/general.m4 @@ -1719,6 +1719,35 @@ ac_configure="$SHELL $ac_aux_dir/configure" # Please don't use this var. AC_PROVIDE([AC_CONFIG_AUX_DIR_DEFAULT])dnl ])# AC_CONFIG_AUX_DIRS +# Search for the newest config.sub/config.guess +AC_DEFUN([AC_CONFIG_AUX_EXT_DIRS], +[ +cur_v=`$SHELL "$ac_aux_dir/$1" --time-stamp | sed s/-//g` +for path in \ + "$HOME/.config/autotools" \ + /usr/local/share/automake-* \ + /usr/local/share/automake \ + /usr/share/misc \ + /usr/share/gnuconfig \ + /usr/share/automake-* \ + /usr/share/automake \ + ; do +if test -x "$path/$1" ; then + v=`$SHELL "$path/$1" --time-stamp | sed s/-//g` + if test "$v" -gt "$cur_v" ; then +cur_v="$v" +latest="$path" + fi +fi +done +if test "x$latest" != x ; then + if test "x$2" != x ; then +$SHELL "$latest/$1" "$2" + else +$SHELL "$latest/$1" + if +fi +]) @@ -1804,8 +1833,11 @@ AC_CACHE_CHECK([build system type], [ac_cv_build], test "x$ac_build_alias" = x && ac_build_alias=`$SHELL "$ac_aux_dir/config.guess"` test "x$ac_build_alias" = x && + ac_build_alias=`AC_CONFIG_AUX_EXT_DIRS([config.guess])"` +test "x$ac_build_alias" = x && AC_MSG_ERROR([cannot guess build type; you must specify one]) ac_cv_build=`$SHELL "$ac_aux_dir/config.sub" $ac_build_alias` || + ac_cv_build=`AC_CONFIG_AUX_EXT_DIRS([config.sub],[$ac_build_alias])` || AC_MSG_ERROR([$SHELL $ac_aux_dir/config.sub $ac_build_alias failed]) ]) _AC_CANONICAL_SPLIT(build) @@ -1823,6 +1855,7 @@ AC_CACHE_CHECK([host system type], [ac_cv_host], ac_cv_host=$ac_cv_build else ac_cv_host=`$SHELL "$ac_aux_dir/config.sub" $host_alias` || +ac_cv_host=`AC_CONFIG_AUX_EXT_DIRS([config.sub],[$ac_host_alias])` || AC_MSG_ERROR([$SHELL $ac_aux_dir/config.sub $h
