bug#62896: [Configure] Bug with check for PERL when path has spaces (i.e. Windows)
On 2023-12-02 19:29, Zack Weinberg wrote: `grep -q` *is* in POSIX, but I seem to recall tripping over a system that didn't have it (probably either a Solaris successor, or AIX) during the run-up to Autoconf 2.71. Solaris 10 /usr/bin/grep does not support -e, -E, -f, -F, -q, or -x. Solaris 10 is supported by its supplier through January 2025; that's the usual guideline we use for how long to support a sorta-POSIX OS. However, the script shouldn't use 'grep'. Instead, it should just use the shell's builtin pattern matching. That's faster and more portable. I installed the attached into Automake. The original bug was fixed before I got to this, so I'm boldly closing the bug report.From 668e8a20e3561063ee7478e91c9f81bb40cfed7a Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 2 Dec 2023 21:50:45 -0800 Subject: [PATCH] Simplify recent $PERL check MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * configure.ac: Don’t spin off subprocesses to check $PERL. --- configure.ac | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index 946fecb67..5cda80a18 100644 --- a/configure.ac +++ b/configure.ac @@ -68,13 +68,16 @@ AUTOMAKE="\"`pwd`/pre-inst-env\" automake-$APIVERSION" AC_PROG_LN_S AC_PATH_PROG([PERL], [perl]) -if test -z "$PERL"; then +case $PERL in + '') AC_MSG_ERROR([perl not found]) -elif echo "$PERL" | grep '[ ]' >/dev/null; then + ;; + *' '* | *' '*) AC_MSG_ERROR([The path to your Perl contains spaces or tabs. This would cause build failures later or unusable programs. Please use a path without spaces and try again.]) -fi + ;; +esac # Save details about the selected perl interpreter in config.log. AM_RUN_LOG([$PERL --version]) -- 2.40.1
bug#62791: BUILT_SOURCES not honoured in parallel build?
On 12 Apr 2023 18:14, Reuben Thomas via Bug reports for Automake wrote: > On Wed, 12 Apr 2023 at 17:59, Reuben Thomas wrote: > > On Wed, 12 Apr 2023 at 16:17, Reuben Thomas wrote: > > > >> I am bootstrapping GNU a2ps git master[1] with automake 1.16.5. When I do > >> a parallel build (in my case, MAKEFLAGS=-j4), I get build failures > >> sometimes: > > > > In fact, I don't need to do a parallel build, just build serially from a > > fresh git checkout, to reproduce this problem. It seems that I must be > > doing something wrong, but I can't work out what! > > I think I've worked it out: I need to add the .c file that is generated > from the .y file, not the .h file, to BUILT_SOURCES. Certainly, doing that > fixes the problem. we prob could add a .y/.l example to the manual. i think i tripped over this error myself in a project in the past. i think you want to list both files. -mike signature.asc Description: PGP signature
bug#62896: [Configure] Bug with check for PERL when path has spaces (i.e. Windows)
On Sat, Dec 2, 2023, at 9:08 PM, Mike Frysinger wrote: > On 02 Dec 2023 15:53, Karl Berry wrote: >> Exit status yes, but at least historically, grep -q has been >> considered non-portable, in favor of grep ... >/dev/null. > > i get that `grep -q` is something historically we've avoided, but i > think it's one of those bad habits we should just get out of. Hmm, `grep -q` *is* in POSIX, but I seem to recall tripping over a system that didn't have it (probably either a Solaris successor, or AIX) during the run-up to Autoconf 2.71. I'm cc:ing Paul Eggert for comment as I believe he's the person who most recently revised the grep section of https://www.gnu.org/software/autoconf/manual/autoconf-2.71/html_node/Limitations-of-Usual-Tools.html . zw
bug#67539: GNU Automake 1.16.5 FAILS one test objc-megademo
On 30 Nov 2023 22:45, Nick Bowler wrote: > Interestingly the libtool manual also says "If [libtool] can't infer a > tag, then it defaults to the configuration for the C language", which is > clearly not the case (it seems what actually happens is that if libtool > can't infer a tag then it exits with a fatal error). So I wonder if > this is actually a regression in libtool. i'm fairly certain libtool used to do this aages ago, and i *think* it stopping was intentional. i recall a lot of pain in Gentoo from that switchup, but tbh, i don't think any of it was "wrong" ... all the fixes we landed were because the code was being misused/abused, and silently doing the wrong thing (especially when cross-compiling). so i personally prefer the new world order, and would say we should lobby for the manual to change rather than rollback the behavior. -mike signature.asc Description: PGP signature
bug#62896: [Configure] Bug with check for PERL when path has spaces (i.e. Windows)
On 02 Dec 2023 15:53, Karl Berry wrote: > also, can we really not trust the exit status of grep ? > if echo "$PERL" | grep -q '[\t ]'; then > > Exit status yes, but at least historically, grep -q has been considered > non-portable, in favor of grep ... >/dev/null. i get that `grep -q` is something historically we've avoided, but i think it's one of those bad habits we should just get out of. i'll note that gnuconfig uses `grep -q` in a bunch of places. not that i'm going to spend time going through the codebase to update all the usage, so if automake itself currently does it this way, OK. > I committed the change as below. --thanks, karl. thanks, lgtm -mike signature.asc Description: PGP signature
bug#64756: rhel8 test failure confirmation?
(Trying to switch to add to https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64756.) this doesn't work on systems that wrap `autom4te`. Had no idea anyone did that. grep: /Autom4te/FileUtils.pm: No such file or directory Oops. seems like the only reliable option is to invoke autom4te. If you can complete the patch ... FWIW, I know that "version" (development sources) autoconf (GNU Autoconf) 2.72c.24-8e728 has the fix, because that's what I've been using. I guess checking for 2.72d and later would suffice, though, since that release is more or less imminent. --thanks, karl.
bug#62896: [Configure] Bug with check for PERL when path has spaces (i.e. Windows)
echo "$PERL" | grep '[ \t]' I don't think there's any portable way to use \t to insert a tab in a shell string, besides literally. There's something like tab=`printf '\t'` .. "$tab" ... but I don't see a need to go that far here. I just used a literal tab char. also, can we really not trust the exit status of grep ? if echo "$PERL" | grep -q '[\t ]'; then Exit status yes, but at least historically, grep -q has been considered non-portable, in favor of grep ... >/dev/null. I committed the change as below. --thanks, karl. -- configure: better check for the perl patch containing whitespace. More for https://bugs.gnu.org/62896. * configure.ac: quote "$PERL" and check directly with grep. diff --git a/configure.ac b/configure.ac index 23a9f97f5..946fecb67 100644 --- a/configure.ac +++ b/configure.ac @@ -70,8 +70,8 @@ AC_PROG_LN_S AC_PATH_PROG([PERL], [perl]) if test -z "$PERL"; then AC_MSG_ERROR([perl not found]) -elif test x"`echo $PERL | grep ' '`" != "x"; then - AC_MSG_ERROR([The path to your Perl contains spaces. +elif echo "$PERL" | grep '[]' >/dev/null; then + AC_MSG_ERROR([The path to your Perl contains spaces or tabs. This would cause build failures later or unusable programs. Please use a path without spaces and try again.]) fi compile finished at Sat Dec 2 14:52:38 2023
bug#67539: GNU Automake 1.16.5 FAILS one test objc-megademo
However it looks like there is no tag defined for Objective C[1]
(presumably it would be --tag=OBJC). Adding this option does appear
to make things "work" in the sense that libtool just complains about
the unknown tag but then proceeds to actually do stuff, rather than
exiting outright with a fatal error.
Thanks Nick.
Does libtool actually work (well enough) with Objective C, then? Apart
from the warning about the tag. I don't see it mentioned in the libtool
sources.
Anyway, I guess it's easy enough to add the tag, if that makes things
better. Why not, I guess? Patch below look right? (Plus maybe something
in the manual.)
BTW, I've been unable to install objc on my systems (Alma 8, Rocky 9)
since installing the gcc-objc + libobjc packages does not suffice.
The result is still:
gcc: error: foo.m: Objective-C compiler not installed on this system
I see some ideas about how to proceed on the net, but ... time.
>From the lack of reports about this test failure (yours was the first,
Dennis, as far as I can recall), I surmise that hardly anyone (who cares
about automake anyway) has objc installed. --thanks, karl.
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -739,6 +739,7 @@ register_language ('name' => 'objc',
'compiler' => 'OBJCCOMPILE',
'compile_flag' => '-c',
'output_flag' => '-o',
+ 'libtool_flag' => 'OBJC',
'lder' => 'OBJCLD',
'ld' => '$(OBJC)',
'pure' => 1,
@@ -757,6 +758,7 @@ register_language ('name' => 'objcxx',
'compiler' => 'OBJCXXCOMPILE',
'compile_flag' => '-c',
'output_flag' => '-o',
+ 'libtool_flag' => 'OBJCXX',
'lder' => 'OBJCXXLD',
'ld' => '$(OBJCXX)',
'pure' => 1,
bug#62896: [Configure] Bug with check for PERL when path has spaces (i.e. Windows)
On 27 May 2023 19:12, Karl Berry wrote: > I (finally) installed this patch to quit early if the perl path has > spaces. Thanks. > > As for MKDIR_P and INSTALL, I guess it is somewhere in the > prerequisite/autoconf stuff. I suppose it would be rare that they would > be found in a path with spaces while perl was not, so I think it's ok to > let that go. --best, karl. > > --- a/configure.ac > +++ b/configure.ac > @@ -71,6 +71,12 @@ AC_PATH_PROG([PERL], [perl]) > if test -z "$PERL"; then > AC_MSG_ERROR([perl not found]) > fi > +if test x"`echo $PERL | grep ' '`" != "x"; then this is expanding $PERL unquoted and letting the shell normalize the whitespace by passing the resulting args to echo. how strict do we need to be with this ? for example, this will let some pathological values pass that shouldn't. $ PERL=" /usr/bin/perl " $ echo $PERL | grep ' '; echo $? 1 the advantage of the check as-written is that it normalizes all whitespace (e.g. tabs) into just spaces which we can grep on. i'm assuming we can't rely on `[:space:]` and such. but maybe including that is portable enough ? echo "$PERL" | grep '[ \t]' also, can we really not trust the exit status of grep ? if echo "$PERL" | grep -q '[\t ]'; then -mike signature.asc Description: PGP signature
