Re: Infinite loop in mdate-sh

[Vincent Lefevre]

On 2005-06-08 20:41:21 +0200, Alexandre Duret-Lutz wrote:
> unset is not portable.  
> Can we override TIME_STYLE with some safe value? Which one? 
> What happens when this is set to the empty string?

An empty string is incorrect:

ay:~> TIME_STYLE= ls -l
ls: ambiguous argument `' for `time style'
Valid arguments are:
  - `full-iso'
  - `long-iso'
  - `iso'
  - `locale'
Try `ls --help' for more information.

So, you should set it to "locale" (this is OK since the script
sets the locales to C).

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

some clean rules don't work when some file starts with '-'

[Vincent Lefevre]

automake 1.10.1 generates a Makefile with:

mostlyclean-compile:
-rm -f *.$(OBJEXT)

This results in:

$ /usr/bin/make clean && echo OK
[...]
rm -f *.o
rm: invalid option -- .
Try `rm ./-.o' to remove the file `-.o'.
Try `rm --help' for more information.
make[1]: [mostlyclean-compile] Error 1 (ignored)
test "" = "" || rm -f *_.c
rm -f *.lo
make[1]: Leaving directory `/home/vlefevre/software/mpfr'
OK

(and make doesn't even exit with a non-zero exit status).
The rule should have been:

mostlyclean-compile:
-rm -f -- *.$(OBJEXT)

or:

mostlyclean-compile:
-rm -f ./*.$(OBJEXT)

Other similar rules are in the same case.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: some clean rules don't work when some file starts with '-'

[Vincent Lefevre]

On 2008-03-21 00:24:20 +0100, Ralf Wildenhues wrote:
> Hello Vincent,
> 
> * Vincent Lefevre wrote on Thu, Mar 20, 2008 at 01:26:21PM CET:
> > mostlyclean-compile:
> > -rm -f *.$(OBJEXT)
> > 
> > This results in:
> 
> > rm -f *.o
> > rm: invalid option -- .
> > Try `rm ./-.o' to remove the file `-.o'.
> 
> Why would you do that, using non-portable file names?

Such filenames can appear, even though they are not part of the source.
In particular, -.o can be generated by gcc. For instance:

  echo 'void tst(void) { }' | gcc -xc -c -

In any case, "make clean" should not be confused by such filenames.

> > mostlyclean-compile:
> > -rm -f ./*.$(OBJEXT)
> 
> FWIW, this wouldn't work (touch ./-a.o ./-b.o).

No problem here. I don't see why this wouldn't work.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: some clean rules don't work when some file starts with '-'

[Vincent Lefevre]

On 2008-03-21 08:24:34 +0100, Ralf Wildenhues wrote:
> But you still can't pass such a file to the linker without additional
> hassles.  So why not use 'gcc -xc -c -o ... -'?

Of course I can use it. But before seeing the error with "make clean",
I didn't know this could be a problem. And such problems could also
happen in the future since in most cases, using "-o ..." is useless
with "-c". Files starting with "-" are allowed by most tools (one
sometimes needs to take care of that, e.g. by using "./" or "--",
depending on the context, but anyway, this is a good habit to take
at least for security reasons).

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

generated Makefile wants to run missing after configure (broken --disable-dependency-tracking?)

[Vincent Lefevre]

I've generated a tarball on a Debian/unstable machine. On the Zaurus,
after running

  ./configure --enable-assert=full --disable-shared \
--disable-dependency-tracking CC=gcc

"make" wants to run "missing":

zaurus:~sd/mpfr-2.3.2-rc1> =make && =make check
cd . && /bin/bash /usr/mnt.rom/card/mpfr-2.3.2-rc1/missing --run aclocal-1.10 
/usr/mnt.rom/card/mpfr-2.3.2-rc1/missing: aclocal-1.10: command not found
WARNING: `aclocal-1.10' is missing on your system.  You should only need it if
 you modified `acinclude.m4' or `configure.in'.  You might want
 to install the `Automake' and `Perl' packages.  Grab them from
 any GNU archive site.
[...]

The file system is a vfat, so that after de-archiving the tarball, the
timestamps are incorrect (the mtime can't be set back in the past).
That's why I use the --disable-dependency-tracking option, but it seems
that it doesn't work.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: generated Makefile wants to run missing after configure (broken --disable-dependency-tracking?)

[Vincent Lefevre]

On 2008-08-27 18:45:24 +0200, Ralf Wildenhues wrote:
> The --disable-dependency-tracking option turns off the mechanism that
> updates .deps/*.Po files which contain dependencies for compiled sources
> like C and C++.  This has nothing to do with rebuild rules.
> 
> You can add AM_MAINTAINER_MODE to your package, see the manual for
> details.

How can one enable maintainer mode *by default*? (Disabling maintainer
mode is really bad in general, as it can lead to obscure broken builds.)

> Or you can try to build your package and create the tarball on the most
> timestamp-challenged file system that you have.  I don't know of a nice
> way to emulate that, though.

I don't understand what you mean. I think that the files in the tarball
should just be ordered in timestamp order.

> BTW, why '=make' instead of 'make'?

In zsh, =make is used to disable a shell function "make" (it will be
expanded to the full pathname).

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: generated Makefile wants to run missing after configure (broken --disable-dependency-tracking?)

[Vincent Lefevre]

On 2008-08-27 19:17:19 +0200, Ralf Wildenhues wrote:
> As in: the configure.ac author gets to decide that if the user of the
> package types
>   ./configure
> 
> then maintainer mode should be enabled, only if she types
>   ./configure --disable-maintainer-mode
> 
> or
>   ./configure --enable-maintainer-mode=no
> 
> then it should be disabled?

Yes.

> If that's your question, then try
>   : ${enable_maintainer_mode=yes}
>   AM_MAINTAINER_MODE
> 
> Drawback: './configure --help' output doesn't imply the correct default
> any more.

This is a bit annoying, but the package could document this point.

Anyway, even if the user doesn't see this documentation, the rebuild
of conf files can be seen in the output, so that there shouldn't be
much surprise.

> What exactly is it that makes you have messed up time stamps?

I think that utime(2) doesn't work. So, when a file is extracted from
the tarball, it gets the current time.

BTW, the "touch" utility is provided by BusyBox v0.60.4 and is very
limited. It isn't even affected by the lack of working utime(2).

> I assumed it was something like this: your source and build tree on
> Debian have good time stamps, then 'make dist' creates a tarball with
> good time stamps.  Then extracting the tarball on the Zaurus somehow
> messes them up.  Correct?

Yes.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: generated Makefile wants to run missing after configure (broken --disable-dependency-tracking?)

[Vincent Lefevre]

On 2008-08-27 11:16:54 -0600, Bob Proulx wrote:
> I think the best and easiest workaround is to set all of the file
> times to the same time.  Then make will consider them up to date.
> 
>   $ cd PROJECTDIR && find . -type f -exec touch -r . {} +
> 
> But if you can't set the time on files then that won't work.

That's precisely the problem: "touch" does not work, except for setting
mtime to the *current* time. I now remember a discussion saying that
"touch" wasn't always implemented, and the default behavior (set to the
current time) was obtained by opening the file and closing it.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: generated Makefile wants to run missing after configure (broken --disable-dependency-tracking?)

[Vincent Lefevre]

On 2008-08-31 06:34:44 +0200, Ralf Wildenhues wrote:
> Other than the workarounds already mentioned in this thread, I don't
> see what Automake can do about it.

Allow the user to choose AM_MAINTAINER_MODE's default in a clean way.

> Really it's the system that should be fixed.

Unfortunately when the system is no longer supported, this is not
possible. Note also that the "touch" utility from the coreutils
still supports systems without utime(2).

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: generated Makefile wants to run missing after configure (broken --disable-dependency-tracking?)

[Vincent Lefevre]

On 2008-08-31 12:19:54 +0200, Ralf Wildenhues wrote:
> * Vincent Lefevre wrote on Sun, Aug 31, 2008 at 12:11:04PM CEST:
> > Allow the user to choose AM_MAINTAINER_MODE's default in a clean way.
> 
> Well, that's one of the already-mentioned workarounds, no?

I mean in a clean way (a bit like AC_DISABLE_SHARED), so that
"configure --help" gives correct output.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: generated Makefile wants to run missing after configure (broken --disable-dependency-tracking?)

[Vincent Lefevre]

On 2008-08-31 10:43:51 -0600, Bob Proulx wrote:
> That was why I posted the workaround for this problem of using touch
> to set all of the timestamps to the current time.  I am not sure you
> noticed it.

I noticed it, but didn't like this workaround because of that,
especially on a handheld:

> If there are a small enough number of files then it is statistically
> likely that this will succeed.  However I acknowledge that if there
> are a large number of files that it might take so long to complete
> that it would cross a clock tick boundary and cross from one into the
> next.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Incorrect information in the manual about the tar-v7 option

[Vincent Lefevre]

Hi,

The automake manual (several versions) says about the tar-v7 option:

 `tar-v7' selects the old V7 tar format.  This is the historical
 default.  This antiquated format is understood by all tar
 implementations and supports file names with up to 99 characters.

This is incorrect. Old versions of BusyBox (such as v1.6.1, currently
used on Nokia's Internet tablets) don't support this format. See:

  https://bugs.maemo.org/show_bug.cgi?id=3033

Shouldn't tar-ustar be the default instead of tar-v7?

Regards,

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: Incorrect information in the manual about the tar-v7 option

[Vincent Lefevre]

On 2008-09-17 22:45:15 +0200, Ralf Wildenhues wrote:
> * Vincent Lefevre wrote on Wed, Sep 17, 2008 at 06:09:43PM CEST:
> > Shouldn't tar-ustar be the default instead of tar-v7?
> 
> I'm not an expert on tar implementations and their issues,
> and what would be a good default nowadays.
> 
> Help?  I Cc:ed a couple of people knowledgeable about tar history,
> and the automake list.  The question how far autotools should cater
> to limitations of new and open source software like BusyBox is quite
> a difficult one to answer in general, to me.  Should autotools add even
> more workarounds, or should rather simply BusyBox be fixed?  Do added
> workarounds here remove the incentive to fix the buggy software there?

I'd say that old, limited, non-standard formats are likely to be less
tested than current ones, thus they are more likely to have problems
with new tools.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

ACDIR should be disabled by default

[Vincent Lefevre]

Hi,

The ACDIR feature leads to various practical problems, such as:

  * Possible clash between software that installs files in
${prefix}/share/aclocal/; in particular, there isn't any namespace
mechanism, it is difficult to say which file belongs to which
software, and this makes debugging difficult (since different
machines will often be likely to show different behaviors).

  * A software that installs a buggy file can more or less break
aclocal, or make it output spurious warning messages, even though
the definitions provided by such a file will not be used by the
software that needs to run the autotools.

  * Performance is degraded for no good reasons.

Thus this feature should be disabled by default, or at least be
deprecated in favor of a cleaner mechanism.

Regards,

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: library rebuilt after "make check"

[Vincent Lefevre]

Hi Ralf,

On 2009-09-18 19:15:12 +0200, Ralf Wildenhues wrote:
> What system and file system is this on, which make implementation and
> version, which autoconf version, do you use the parallel-tests option,
> and when will mpfr.org be online again?

Mac OS X (PowerPC) 10.4.11, HFS+, GNU Make 3.80, GNU Autoconf 2.64,
GNU libtool 2.2.6, make -j2.

mpfr.org should be back online on Saturday at 18:00 UTC.
https://gforge.inria.fr/projects/mpfr/ is hosted somewhere else,
thus is accessible.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: library rebuilt after "make check"

[Vincent Lefevre]

[Added Paul to Cc, there's something for you.]

On 2009-09-19 09:29:44 +0200, Ralf Wildenhues wrote:
> Thanks.  Please fix the wording on
>  to state that, for checking
> out the project source code repo, one only needs .../svn/mpfr/trunk, and
> not the command listed which also checks out www pages, old tarballs,
> branches, tags, and all.

Unfortunately this is not possible (a Gforge limitation). All that
I could obtain from the admins is the possibility to have an
additional message at the end. I've just done that, but this
is not very visible. :(

> Notes to the sources:
> 
> Please use the patch below to also let non-GNU make see the dependency
> on the libmpfr.la file of the programs (so they are relinked if the
> library is updated).  Non-GNU make don't identify ./FILE with FILE.

Thanks. Done in both the trunk and the 2.4 branch.

> What is LOADLIBES in tests/Makefile.am used for?

r3206 | zimmerma | 2005-01-21 13:20:54 +0100 (Fri, 21 Jan 2005) | 2 lines

added LOADLIBES=...

Paul?

> Please line-wrap libmpfr_la_SOURCES, you're over 2K already which is the
> limit for some vendor grep that then cut silently (the build system
> might use grep on Makefile.am).  I don't think Darwin is in the boat
> with this issue, it's definitely not on the 8.11.0 I've just tried.

Done. Thanks for the information.

> BTW, do you still have a complete log of the first 'make'?

Unfortunately no (BTW, I wish log files would be generated by default).

> Was set_flt.lo even compiled at all the first time?

I don't know (not possible to see).

> Was automake rerun at that time?

It was rerun at the beginning at least.

> Is this a reproducible issue?

I don't know yet, but this is the first time I have such a problem
though I use this machine very often to develop MPFR.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

bug#11007: incorrect dependency style (depmode) of tcc

[Vincent Lefevre]

I've reported the following bug on the Debian BTS:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663705

for Automake 1.11.3.

When I configure MPFR with CC=tcc, as soon as a .c file is modified or
I do a "make clean", I get errors when I want to rebuild MPFR.

For instance, after a "make clean" and "make":

Making all in doc
make[1]: Entering directory `/home/vlefevre/software/mpfr/doc'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/vlefevre/software/mpfr/doc'
Making all in src
make[1]: Entering directory `/home/vlefevre/software/mpfr/src'
/usr/bin/make  all-am
make[2]: Entering directory `/home/vlefevre/software/mpfr/src'
exceptions.c \ :
/home/vlefevre/dash/bin/dash: exceptions.c: Permission denied
make[2]: *** [exceptions.lo] Error 126
make[2]: Leaving directory `/home/vlefevre/software/mpfr/src'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/vlefevre/software/mpfr/src'
make: *** [all-recursive] Error 1
zsh: exit 2 =make

The problem appears to be due to the src/.deps/*.Plo files.

In the config.log file:

configure:4362: checking dependency style of tcc
configure:4473: result: icc

Of course, there's no such problem with --disable-dependency-tracking.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#17764: autom4te version is not remembered (for maintainer mode)

[Vincent Lefevre]

I use 2 autoconf versions:

$ autoconf --version
autoconf (GNU Autoconf) 2.69
[...]
$ $HOME/autoconf/bin/autoconf --version
autoconf (GNU Autoconf) 2.69.115-251d1-dirty
[...]

With MPFR:

$ $HOME/autoconf/bin/autoreconf
$ ./configure AUTOCONF=$HOME/autoconf/bin/autoconf 
AUTOHEADER=$HOME/autoconf/bin/autoheader AUTOM4TE=$HOME/autoconf/bin/autom4te
$ make clean
$ touch configure.ac
$ make
CDPATH="${ZSH_VERSION+.}:" && cd . && /home/vlefevre/dash/bin/dash 
/home/vlefevre/software/mpfr/missing aclocal-1.14 -I m4
CDPATH="${ZSH_VERSION+.}:" && cd . && /home/vlefevre/autoconf/bin/autoconf
 cd . && /home/vlefevre/dash/bin/dash /home/vlefevre/software/mpfr/missing 
automake-1.14 --gnu
aclocal.m4:17: warning: this file was generated for autoconf 2.69.
You have another version of autoconf.  It may work, but is not guaranteed to.
If you have problems, you may need to regenerate the build system entirely.
To do so, use the procedure documented by the package, typically 'autoreconf'.
[...]

If I use

  export AUTOM4TE=$HOME/autoconf/bin/autom4te

everything is fine, but the autom4te version should be remembered
via "configure" settings because the locally changed environment
is lost with the terminal session.

I suppose that the AUTOM4TE value should be defined in the Makefile
(just like AUTOCONF and AUTOHEADER) and provided to the aclocal
invocation.

The problem can't even be solved by the following:

$ $HOME/autoconf/bin/autoreconf
$ ./configure AUTOCONF=$HOME/autoconf/bin/autoconf 
AUTOHEADER=$HOME/autoconf/bin/autoheader ACLOCAL="env 
AUTOM4TE=$HOME/autoconf/bin/autom4te aclocal"
$ make clean
$ touch configure.ac
$ make
CDPATH="${ZSH_VERSION+.}:" && cd . && env 
AUTOM4TE=/home/vlefevre/autoconf/bin/autom4te aclocal -I m4
CDPATH="${ZSH_VERSION+.}:" && cd . && /home/vlefevre/autoconf/bin/autoconf
 cd . && /home/vlefevre/dash/bin/dash /home/vlefevre/software/mpfr/missing 
automake-1.14 --gnu
/home/vlefevre/dash/bin/dash ./config.status --recheck
aclocal.m4:17: warning: this file was generated for autoconf 
2.69.115-251d1-dirty.
You have another version of autoconf.  It may work, but is not guaranteed to.
If you have problems, you may need to regenerate the build system entirely.
To do so, use the procedure documented by the package, typically 'autoreconf'.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#18662: Local -L flags for "make check" appear too late under HP-UX

[Vincent Lefevre]

I reported the following bug

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9728

against libtool a few years ago, but it was said that the bug was in
autoconf or automake (then, I suspect automake). I don't know whether
something has been done on the automake side; I don't have access to
HP-UX machines any longer.

The problem is the following.

To be able to build the MPFR library, the user may need to add some
search path when invoking configure, in order to find the GMP library
(on which MPFR depends). This is done via LDFLAGS, either explicitly
or by the configure script if the user has provided a --with-gmp=DIR
option. The setting of LDFLAGS for such a purpose is standard and
documented in the Automake manual (AM_LDFLAGS could be used too, with
the same effect).

Then, for "make check", the path to the MPFR library that has just
been built or the library filename itself must be added to the link
command by the autotools (automake?). Under GNU/Linux, the filename
../src/.libs/libmpfr.so is used, and there are no problems. But under
HP-UX, it is the path that is added (here, the -L../src/.libs flag),
and this is done in LIBS, which appears at the end of the command,
and in particular *after* $(LDFLAGS):

LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
--mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
$(LDFLAGS) -o $@

tversion$(EXEEXT): $(tversion_OBJECTS) $(tversion_DEPENDENCIES)
@rm -f tversion$(EXEEXT)
$(LINK) $(tversion_OBJECTS) $(tversion_LDADD) $(LIBS)

which gives for instance:

libtool: link: gcc -O2 -s -o tversion tversion.o  -L/opt/gnu/lib 
./.libs/libfrtests.a -lm -L../src/.libs -lmpfr -lgmp -Wl,+b 
-Wl,/xxx/gnu/mpfr-3.1.0/objdir/src/.libs:/opt/gnu/lib

(see the -L/opt/gnu/lib before -L../src/.libs).

This means that search paths added via AM_LDFLAGS and/or LDFLAGS have
the precedence over the local search path, and if an old version of
the library is installed in some LDFLAGS search path (which happens),
it will be used for "make check" instead of the library that has just
been built.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#22856: "make check" can start a shell on binary data

[Vincent Lefevre]

When I cross-compile for Windows and run "make check" without
LOG_COMPILER=wine (by mistake), strange files appear.
For instance, as a simple example with MPFR:

cventin:...re/mpfr-3.1/tests> make tadd.log
FAIL: tadd.exe

The failure is expected, but I get:

-rw-r--r-- 1491 2016-02-29 19:39:24 tadd.log
-rw-r--r-- 1 84 2016-02-29 19:39:24 tadd.trs
-rw-r--r-- 1  0 2016-02-29 19:39:24 \220\324V\366

Created files like "\220\324V\366" are very annoying. In particular,
they make svn unusable.

tadd.log contains:

./tadd.exe: 1: ./tadd.exe: MZ��¸@€º´: not found
./tadd.exe: 2: ./tadd.exe: : not found
./tadd.exe: 1: ./tadd.exe: @.bss €: not found
./tadd.exe: 1: ./tadd.exe: .textd*,: not found
./tadd.exe: 3: ./tadd.exe: JPL2@�.idata: not found
./tadd.exe: 3: ./tadd.exe: –u
 : not found
./tadd.exe: 4: ./tadd.exe: ~@0�.CRT4�ˆ@0�.tls: not found
./tadd.exe: 5: ./tadd.exe: @B/81P: not found
./tadd.exe: 13: ./tadd.exe: Syntax error: Missing '}'
FAIL tadd.exe (exit status: 2)

So, it appears that tadd.exe (which is a binary[*]) was executed
by a shell!

[*]
$ file tadd.exe
tadd.exe: PE32 executable (console) Intel 80386, for MS Windows

This is confirmed by strace:

[...]
10517 execve("./tadd.exe", ["./tadd.exe"], [/* 116 vars */]) = -1 ENOEXEC (Exec 
format error)
10517 execve("/bin/sh", ["/bin/sh", "./tadd.exe"], [/* 116 vars */]) = 0
[...]

Concerning the Makefile in the tests:

# Makefile.in generated by automake 1.15 from Makefile.am.
# tests/Makefile.  Generated from Makefile.in by configure.

This is under Debian/unstable.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#22856: "make check" can start a shell on binary data

[Vincent Lefevre]

Sorry, forget this bug report. After wondering where the problem came
from exactly, I've eventually found that this is some incredible bug
in dash!

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#40699: "dist Hook" documentation in manual is incorrect or unclear about write permissions

[Vincent Lefevre]

doc/automake.texi contains:


@example
EXTRA_DIST = doc
dist-hook:
rm -rf `find $(distdir)/doc -type d -name .svn`
@end example

@c The caveats described here should be documented in 'disthook.sh'.
@noindent
Note that the @code{dist-hook} recipe shouldn't assume that the regular
files in the distribution directory are writable; this might not be the
case if one is packaging from a read-only source tree, or when a
@code{make distcheck} is being done.  For similar reasons, the recipe
shouldn't assume that the subdirectories put into the distribution
directory as an effect of having them listed in @code{EXTRA_DIST} are
writable.  So, if the @code{dist-hook} recipe wants to modify the
content of an existing file (or @code{EXTRA_DIST} subdirectory) in the
distribution directory, it should explicitly to make it writable first:

@example
EXTRA_DIST = README doc
dist-hook:
chmod u+w $(distdir)/README $(distdir)/doc
echo "Distribution date: `date`" >> README
rm -f $(distdir)/doc/HACKING
@end example


So, if the subdirectories may not be writable, how can the rm in the
first example work without changing the permissions first?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#40699: "dist Hook" documentation in manual is incorrect or unclear about write permissions

[Vincent Lefevre]

On 2020-04-18 15:04:08 -0600, Karl Berry wrote:
> Hi Vincent,
> 
> So, if the subdirectories may not be writable, how can the rm in the
> first example work without changing the permissions first?
> 
> [namely:]
> dist-hook:
> rm -rf `find $(distdir)/doc -type d -name .svn`
> 
> That example belongs to the preceding paragraph 
>   (Occasionally it is useful to be able to change the distribution ...)
> not the following paragraph that you quoted.

I know, but the paragraph that follows shows an issue with this
example.

> Also, not that I wrote any of this, but it seems to me that the
> pervasive assumption is that the automake user in fact owns the file
> trees in question. Thus rm -rf should work even if it's mode zero.

No, it doesn't. At least not with

  rm (GNU coreutils) 8.30

i.e. it does not change the permissions in order to make the removal
work recursively (the -f just means that it ignores nonexistent files
and that it will never prompt for confirmation).

> Of course it won't work on a read-only source tree, but, well, it's just
> an example ... --thanks, karl.

It's just an example, but it should be correct (at least if there are
no warnings about things that have been dropped to make it simpler).
A user may want to copy-paste this example, and he will get something
incorrect.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#40699: "dist Hook" documentation in manual is incorrect or unclear about write permissions

[Vincent Lefevre]

On 2020-04-18 19:11:14 -0400, Nick Bowler wrote:
> I guess the note about dist-hooks when packaging from a read-only srcdir
> was added because of my bug report[1].
> 
> I have never noticed read-only _directories_ in the distdir before (I
> have assumed they are always created read-write so that Automake can
> put distributed files in them) but I also don't ever put directory
> names in EXTRA_DIST which is the case specifically called out in the
> documentation.
> 
> I think it's kind of weird that distribution permissions can depend on
> how the package tarball was unpacked so since then I always use
> dist-hook to fix up permissions in $(distdir) before anything else.
> 
> [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=10878

I can reproduce the issue with "make dist" and code like the example

 EXTRA_DIST = doc
 dist-hook:
 rm -rf `find $(distdir)/doc -type d -name .svn`

when the directory is read-only. But if the directory is not
read-only, "make distcheck" does not fail. So it seems that
"make distcheck" no longer tests "make dist" from a read-only
source tree (it tests the build from a read-only source tree,
but for "make dist", it first extracts the tarball in the
build directory then runs "make dist" from the new copy of
the source tree, which is not read-only).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#40699: "dist Hook" documentation in manual is incorrect or unclear about write permissions

[Vincent Lefevre]

On 2020-04-20 14:59:00 -0600, Karl Berry wrote:
> i.e. it does not change the permissions in order to make the removal
> work recursively
> 
> Right, I see it now. Had been testing the wrong thing.
> 
> So, can you propose a specific change for the manual? -k

I think that it is sufficient to fix the example (the explanation
is just below). BTW, the second example is also incorrect.

commit a639e5b51cadbaff88ca4059b4db4571c811070c
Author: Vincent Lefevre 
Date:   2020-04-23 17:33:54 +0200

doc: fix dist-hook examples

diff --git a/doc/automake.texi b/doc/automake.texi
index 469a72971..1b35883b9 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -8497,6 +8497,7 @@ a directory in @code{EXTRA_DIST}:
 @example
 EXTRA_DIST = doc
 dist-hook:
+chmod -R u+w $(distdir)/doc
 rm -rf `find $(distdir)/doc -type d -name .svn`
 @end example
 
@@ -8516,7 +8517,7 @@ distribution directory, it should explicitly to make it 
writable first:
 EXTRA_DIST = README doc
 dist-hook:
 chmod u+w $(distdir)/README $(distdir)/doc
-echo "Distribution date: `date`" >> README
+echo "Distribution date: `date`" >> $(distdir)/README
 rm -f $(distdir)/doc/HACKING
 @end example
 

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#55025: Automake should allow one to enable POSIX make behavior

[Vincent Lefevre]

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html
says about the target rules:

  .POSIX
The application shall ensure that this special target is specified
without prerequisites or commands. If it appears as the first
non-comment line in the makefile, /make/ shall process the makefile
as specified by this section; otherwise, the behavior of /make/ is
unspecified.

But even though one may add a .POSIX target as the first non-comment
line in one's Makefile.am file, Automake will add various non-comment
lines before this target in the generated Makefile. I received a
remark about that for GNU MPFR. Though GNU make does not require
this target to be the first non-comment line, this may matter with
other make implementations.

This could be done either by detecting a .POSIX target in Makefile.am
or with some AM_* macro in the configure.ac file.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#55025: Automake should allow one to enable POSIX make behavior

[Vincent Lefevre]

On 2023-01-13 01:19:39 -0500, Mike Frysinger wrote:
> any reason we don't just define it ourselves unconditionally ?  seems
> like the whole point of Automake is for devs to not worry about these
> kind of nitty details.

Probably. Note, however, that .POSIX affects GNU "make" on a few
points (the default is obviously not portable, but some developers
might require GNU "make", though probably for other reasons):

   If the '.POSIX' special target is defined then backslash/newline
handling is modified slightly to conform to POSIX.2: first, whitespace
preceding a backslash is not removed and second, consecutive
backslash/newlines are not condensed.

 In particular, if this target is mentioned then recipes will be
 invoked as if the shell had been passed the '-e' flag: the first
 failing command in a recipe will cause the recipe to fail
 immediately.

'warning: ignoring prerequisites on suffix rule definition'
 According to POSIX, a suffix rule cannot contain prerequisites.  If
 a rule that could be a suffix rule has prerequisites it is
 interpreted as a simple explicit rule, with an odd target name.
 This requirement is obeyed when POSIX-conforming mode is enabled
 (the '.POSIX' target is defined).  In versions of GNU 'make' prior
 to 4.3, no warning was emitted and a suffix rule was created,
 however all prerequisites were ignored and were not part of the
 suffix rule.  Starting with GNU 'make' 4.3 the behavior is the
 same, and in addition this warning is generated.  In a future
 version the POSIX-conforming behavior will be the only behavior: no
 rule with a prerequisite can be suffix rule and this warning will
 be removed.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#55025: Automake should allow one to enable POSIX make behavior

[Vincent Lefevre]

On 2023-01-14 01:30:24 -0500, Nick Bowler wrote:
> Does adding .POSIX: to a Makefile actually solve any real-world
> portability problem with Automake generated makefiles, or is all of
> this just hypothetical?

For MPFR, when I initially added it, this was just in case.

The real issue at that time was that I was using $< in a case
where it was unspecified by POSIX, and this was failing on FreeBSD.
Unfortunately there doesn't seem to be a way to get a failure
on non-portable features (which would ease maintenance). Though
I test the tarball on various systems before a release candidate,
this is not the case of the development branch (and the Makefiles
would typically be more affected than the C code, on which various
portability checks are done under Linux).

Well, I use autoreconf with --warnings=all,error (passed to automake),
but I didn't get any portability error.

Later I noted:

# The ".POSIX" line is needed in particular for GNU "make", so that
# recipes are invoked as if the shell had been passed the -e flag.

as this is really what we want, both for consistency with other
"make" implementations and to be able to detect errors.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#55025: Automake should allow one to enable POSIX make behavior

[Vincent Lefevre]

On 2023-01-14 15:12:00 -0700, Karl Berry wrote:
> P.S. I note that GNU make just made an alpha release. If anyone
> wants to report the purported .POSIX bug, might be a good time.

I've just reported it:

  https://savannah.gnu.org/bugs/index.php?63667

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#55025: Automake should allow one to enable POSIX make behavior

[Vincent Lefevre]

On 2023-01-14 01:30:24 -0500, Nick Bowler wrote:
> Consider these two Makefiles, identical except for the presence of
> the .POSIX special target:
> 
>   % cat >noposix.mk <<'EOF'
>   craziness:
>   @-false; echo hello
>   @false; echo hello
> EOF
> 
>   % cat >posix.mk <<'EOF'
>   .POSIX:
>   craziness:
>   @-false; echo hello
>   @false; echo hello
> EOF
[...]
> HP-UX 11:
> 
>   (this is the actual POSIX-specified behaviour which I also observed on
>   multiple other systems):
> 
>   % make -f noposix.mk
>   hello
>   *** Error exit code 1
> 
>   Stop.
> 
>   % make -f posix.mk
>   hello
>   *** Error exit code 1

Same behavior on AIX, i.e. the .POSIX special target is useless for
*this* example. However, if it is not the first non-comment line, I
get a warning:

  warning: .POSIX directive is not first non-comment line.

(found during my test of GNU MPFR on cfarm119.cfarm.net).

Note that its "make" man page says:

  .POSIX
  Causes the make command to use a different default rules file. The
  file, /usr/ccs/lib/posix.mk, provides the default rules as
  specified in the POSIX standard.

but I don't know whether this changes the behavior with Automake.

If /usr/ccs/lib/posix.mk is included when the .POSIX directive is read,
the fact that it is not the first non-comment line might cause issues.
For instance, this file (re)defines some variables:

MAKE=make
AR=ar
ARFLAGS=-rv
YACC=yacc
YFLAGS=
LEX=lex
LFLAGS=
LDFLAGS=
CC=c89
CFLAGS=-O
FC=fort77
FFLAGS=-O 1
GET=get
GFLAGS=

So this is expected to be found early in the makefile.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#55025: Automake should allow one to enable POSIX make behavior

[Vincent Lefevre]

On 2023-10-02 15:17:13 -0600, Karl Berry wrote:
> Sorry, I don't understand what you want Automake to do.
> 
> Right now, as far as I can tell, Automake does nothing with .POSIX. It's
> not mentioned in the manual nor, as far as I can grep, the code. Maybe
> that's the issue, and you want a leading .POSIX in your Makefile.am to
> be specially copied at the beginning of the output Makefile.in?
> (Or an option, or something.)

Yes, Automake should either detect a ".POSIX:" in the Makefile.am
file (at least if it is the first non-comment line) and place it at
the beginning of Makefile.in, or provide an option to be used with
AM_INIT_AUTOMAKE (or AUTOMAKE_OPTIONS) in order to have a ".POSIX:"
at the beginning of Makefile.in.

> But ... have you tried to run a Makefile originating from Automake with
> .POSIX in effect?  I feel doubtful that it will work, although I don't
> know it for a fact.  -k

The Makefile.am files of GNU MPFR have a ".POSIX:" target as the
first non-comment line: the shell for recipes is expected to be
run with the -e flag. So, the ".POSIX:" is necessary for GNU Make
in order to detect errors[*] (fortunately, GNU Make does not seem
to care about its position in Makefile).

[*] It is not needed for a successful build, but its absence might
yield successful builds that are actually broken.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#55025: Automake should allow one to enable POSIX make behavior

[Vincent Lefevre]

On 2023-10-03 15:08:42 -0600, Karl Berry wrote:
> Yes, Automake should either detect a ".POSIX:" in the Makefile.am
> file (at least if it is the first non-comment line) and place it at
> the beginning of Makefile.in, or provide an option to be used with
> AM_INIT_AUTOMAKE (or AUTOMAKE_OPTIONS) in order to have a ".POSIX:"
> at the beginning of Makefile.in.
> 
> Ok. I welcome patches for either or both. It's not something I'll be
> implementing myself any time soon (regrettably).

I think that a "posix" option is cleaner and simpler to implement.
I have some idea of a patch. I'll try to look at it more closely
late tonight.

> The Makefile.am files of GNU MPFR have a ".POSIX:" target 
> 
> Glad to know it works in practice for you. I'm just surprised that
> nothing in Automake's make output breaks under POSIX. --thanks, karl.

On platforms with a POSIX "make", the generated makefile needs to
work as expected. This limits the risk of breakage when using a
".POSIX:" target.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#66352: parallel make yields "find: ‘./conf*.dir’: No such file or directory" errors

[Vincent Lefevre]

When I want to build Automake (current Git version) with
a parallel make ("make -j12"):

  MAKEINFO doc/automake-history.info
  GEN  bin/automake
  GEN  bin/aclocal
  GEN  t/ax/shell-no-trail-bslash
  GEN  t/ax/cc-no-c-o
  GEN  doc/aclocal.1
  GEN  runtest
  GEN  doc/automake.1
  GEN  doc/amhello-1.0.tar.gz
make[1]: Entering directory '/home/vlefevre/software/automake'
  GEN  lib/Automake/Config.pm
  GEN  t/ax/test-defs.sh
find: ‘./conf272281.dir’: No such file or directory
find: ‘./conf272280.dir’: No such file or directory
find: ‘./conf272301.dir’: No such file or directory
make[1]: Leaving directory '/home/vlefevre/software/automake'
Updating ./doc/version.texi
  MAKEINFO doc/automake.info
  GEN  bin/aclocal-1.16
  GEN  doc/aclocal-1.16.1
  GEN  bin/automake-1.16
  GEN  doc/automake-1.16.1
+++make: INTERNAL: Exiting with 1 jobserver tokens available; should be 
12!

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#66353: test suite: aclocal-I-and-install failure

[Vincent Lefevre]

Under Debian/unstable, when testing the automake Git version
(80714ea0aba62f025780f432abfbab2e66f6f801), aclocal-I-and-install
is one of the two tests that fail.

I've attached the t/aclocal-I-and-install.log file.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Running from installcheck: no
Test Protocol: none
PATH = 
/home/vlefevre/software/automake/bin:/home/vlefevre/software/automake/t/ax:/home/vlefevre/eftests/bin:/home/vlefevre/bin:/home/vlefevre/x86_64/bin:/home/vlefevre/opt/tcc/bin:/home/vlefevre/perl5/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/games
+ pwd
/home/vlefevre/software/automake/t/aclocal-I-and-install.dir
+ cat
+ ACLOCAL=aclocal-1.16 -Werror --system-acdir acdir
+ mkdir m4_1 m4_2 acdir acdir2
+ echo ./acdir2
+ cat
+ cat
+ cat
+ aclocal-1.16 -Werror --system-acdir acdir -I m4_1 -I m4_2
+ autoconf
/usr/share/autoconf/autoconf/trailer.m4:4: warning: AC_OUTPUT was never used
+ /bin/grep -F :macro11: configure
:macro11:
+ /bin/grep -F :macro21: configure
:macro21:
+ /bin/grep -F :macro33: configure
:macro33:
+ grep MACRO3 aclocal.m4
AC_DEFUN([MACRO3], [:macro33:])
+ test ! -e m4_1/macro.m4
+ test ! -e m4_2/macro.m4
+ sleep 0.2
+ aclocal-1.16 -Werror --system-acdir acdir -I m4_2 -I m4_1
+ autoconf
/usr/share/autoconf/autoconf/trailer.m4:4: warning: AC_OUTPUT was never used
+ /bin/grep -F :macro12: configure
:macro12:
+ /bin/grep -F :macro21: configure
:macro21:
+ /bin/grep -F :macro33: configure
:macro33:
+ grep MACRO3 aclocal.m4
AC_DEFUN([MACRO3], [:macro33:])
+ test ! -e m4_1/macro.m4
+ test ! -e m4_2/macro.m4
+ sleep 0.2
+ aclocal-1.16 -Werror --system-acdir acdir -I m4_1 -I m4_2 --install
aclocal-1.16: installing 'm4_1/macro.m4' from 'acdir2/macro.m4'
+ autoconf
/usr/share/autoconf/autoconf/trailer.m4:4: warning: AC_OUTPUT was never used
+ /bin/grep -F :macro11: configure
+ am_exit_trap 1
+ exit_status=1
+ set +e
+ cd /home/vlefevre/software/automake
+ test none = tap
+ test 1 -eq 0
+ keep_testdirs=yes
+ am_keeping_testdirs
+ return 0
+ set +x
FAIL t/aclocal-I-and-install.sh (exit status: 1)

bug#66354: test suite: remake-after-aclocal-m4 failure

[Vincent Lefevre]

Under Debian/unstable, when testing the automake Git version
(80714ea0aba62f025780f432abfbab2e66f6f801), remake-after-aclocal-m4
is one of the two tests that fail.

I've attached the t/remake-after-aclocal-m4.log file.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Running from installcheck: no
Test Protocol: none
PATH = 
/home/vlefevre/software/automake/bin:/home/vlefevre/software/automake/t/ax:/home/vlefevre/eftests/bin:/home/vlefevre/bin:/home/vlefevre/x86_64/bin:/home/vlefevre/opt/tcc/bin:/home/vlefevre/perl5/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/games
+ pwd
/home/vlefevre/software/automake/t/remake-after-aclocal-m4.dir
+ magic1=::MagicStringOne::
+ magic2=__MagicStringTwo__
+ using_gmake
+ make --version -v
+ grep GNU
GNU Make 4.3
License GPLv3+: GNU GPL version 3 or later 
+ am__using_gmake=yes
+ return 0
+ cat
+ cat
+ cat
+ echo cat
+ aclocal-1.16 -Werror
+ sed /^ *#.*generated automatically/d aclocal.m4
+ mv -f t aclocal.m4
+ autoconf
+ automake-1.16 --foreign -Werror -Wall
+ :
+ mkdir build
+ cd build
+ srcdir=..
+ ../configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether sleep supports fractional seconds... true
checking the filesystem timestamp resolution... 0.2
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking xargs -n works... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating foo.sh
+ make
make: Nothing to be done for 'all'.
+ sleep 0.2
+ echo AC_DEFUN([my_fingerprint], [::MagicStringOne::])dnl %%%
+ remake_
+ make nil
 cd .. && /bin/sh 
/home/vlefevre/software/automake/t/remake-after-aclocal-m4.dir/missing 
automake-1.16 --foreign
CDPATH="${ZSH_VERSION+.}:" && cd .. && /bin/sh 
'/home/vlefevre/software/automake/t/remake-after-aclocal-m4.dir/missing' 
autoconf
/bin/sh ./config.status --recheck
running CONFIG_SHELL=/bin/sh /bin/sh ../configure build_alias= host_alias= 
--no-create --no-recursion
checking for a BSD-compatible install... /usr/bin/install -c
checking whether sleep supports fractional seconds... true
checking the filesystem timestamp resolution... 0.2
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking xargs -n works... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
 /bin/sh ./config.status
config.status: creating Makefile
config.status: creating foo.sh
make: Nothing to be done for 'nil'.
+ /bin/grep -F FINGERPRINT Makefile
FINGERPRINT = ::MagicStringOne::
test x'$(FINGERPRINT)' = x'DummyValue'
+ /bin/grep -F ::MagicStringOne:: Makefile
FINGERPRINT = ::MagicStringOne::
+ ./foo.sh
+ test x::MagicStringOne:: = x::MagicStringOne::
+ sleep 0.2
+ echo sed 's/.*dnl *%%%.*/AC_DEFUN([my_fingerprint], [__MagicStringTwo__])/'
+ remake_
+ make nil
/bin/sh ../tweak-aclocal-m4 <../aclocal.m4 >../aclocal.m4-t
mv -f ../aclocal.m4-t ../aclocal.m4
touch ../aclocal.m4
 cd .. && /bin/sh 
/home/vlefevre/software/automake/t/remake-after-aclocal-m4.dir/missing 
automake-1.16 --foreign
CDPATH="${ZSH_VERSION+.}:" && cd .. && /bin/sh 
'/home/vlefevre/software/automake/t/remake-after-aclocal-m4.dir/missing' 
autoconf
/bin/sh ./config.status --recheck
running CONFIG_SHELL=/bin/sh /bin/sh ../configure build_alias= host_alias= 
--no-create --no-recursion
checking for a BSD-compatible install... /usr/bin/install -c
checking whether sleep supports fractional seconds... true
checking the filesystem timestamp resolution... 0.2
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking xargs -n works... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
 /bin/sh ./config.status
config.status: creating Makefile
config.status: creating foo.sh
make: Nothing to be done for 'nil'.
+ /bin/grep -F FINGERPRINT Makefile
FINGERPRINT = __MagicStringTwo__
test x'$(FINGERPRINT)' = x'DummyValue'
+ /bin/grep -F ::MagicStringOne:: Makefile
+ /bin/grep -F __MagicStringTwo__ Makefile
FINGERPRINT = __MagicStringTwo__
+ ./foo.sh
+ test x__MagicStringTwo__ = x__MagicStringTwo__
+ sleep 0.2
+ echo cat
+ echo AC_DEFUN([my_fingerprint], [DummyValue])
+ using_gmake
+ return 0
+ make distcheck
 cd .. && /bin/sh 
/home/vlefevre/software/automake/t/remake-a

bug#55025: [PATCH] New "posix" automake option.

[Vincent Lefevre]

This patch is from https://bugs.gnu.org/55025.

* lib/Automake/Options.pm: declare "posix" option.
* bin/automake.in: if the "posix" option is present, add
a .POSIX special target as the first non-comment line in
the Makefile.in files.
* NEWS: mention this.
* doc/automake.texi: likewise.
---
 NEWS| 2 ++
 bin/automake.in | 7 +++
 doc/automake.texi   | 6 ++
 lib/Automake/Options.pm | 1 +
 4 files changed, 16 insertions(+)

diff --git a/NEWS b/NEWS
index ced0fd640..821ae0cf1 100644
--- a/NEWS
+++ b/NEWS
@@ -30,6 +30,8 @@ New in 1.17:
 as given in the Makefile.am will be used.  If @setfilename is present,
 it should be the basename of the Texinfo file, extended with .info.
 
+  - New option "posix" to generate a .POSIX special target.
+
 * Bugs fixed
 
   - Generated file timestamp checks now handle filesystems with sub-second
diff --git a/bin/automake.in b/bin/automake.in
index 369a47fa2..edc0488b8 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -8126,6 +8126,13 @@ sub generate_makefile
   my $output =
 "$output_vars$output_all$output_header$output_rules$output_trailer";
 
+  # The .POSIX special target must be the first non-comment line;
+  # otherwise, the behavior of "make" is unspecified by POSIX.
+  if (option 'posix')
+{
+  $output =~ s/^((#.*)?\n)*\K/.POSIX:\n\n/;
+}
+
   # Decide whether we must update the output file or not.
   # We have to update in the following situations.
   #  * $force_generation is set.
diff --git a/doc/automake.texi b/doc/automake.texi
index d14b769fd..97e3e3475 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -10679,6 +10679,12 @@ are ordinarily automatically provided by Automake.
 Don't require @file{texinfo.tex}, even if there are texinfo files in
 this directory.
 
+@item @option{posix}
+@cindex Option, @option{posix}
+@opindex posix
+Generate a @code{.POSIX} special target as the first non-comment line in
+the @file{Makefile.in} files.
+
 @item @option{serial-tests}
 @cindex Option, @option{serial-tests}
 @opindex serial-tests
diff --git a/lib/Automake/Options.pm b/lib/Automake/Options.pm
index 69fc2ecb5..22d527fac 100644
--- a/lib/Automake/Options.pm
+++ b/lib/Automake/Options.pm
@@ -290,6 +290,7 @@ sub _is_valid_easy_option ($)
 no-installman
 no-texinfo.tex
 nostdinc
+posix
 readme-alpha
 serial-tests
 parallel-tests
-- 
2.42.0

bug#66354: test suite: remake-after-aclocal-m4 failure

[Vincent Lefevre]

On 2023-10-05 15:18:39 -0600, Karl Berry wrote:
> Thanks. I wonder if this and aclocal-I-and-install fail consistently for
> you. There is a timing issue with development automake that requires
> development autoconf (for a one-character fix in autom4te). Info:
> https://bugs.gnu.org/64756.

Indeed, these are random failures.

"make check" 1:
FAIL: t/aclocal-I-and-install
FAIL: t/backcompat2
FAIL: t/nodef

"make check" 2:
no failures

"make check" 3:
FAIL: t/aclocal-I-and-install
FAIL: t/remake-all-2

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

bug#66352: parallel make yields "find: ���./conf*.dir���: No such file or directory" errors

[Vincent Lefevre]

On 2023-11-03 10:28:38 -0600, Karl Berry wrote:
> When I want to build Automake (current Git version) with
> a parallel make ("make -j12"):
> 
> I surmise this one was caused by the same random timing failures as your
> other reports, 66353 and 66354.
> 
> A couple days ago we finally installed a patch (thanks Bogdan and Jacob)
> so that development automake should no longer require development
> autoconf in order to avoid these problems. I.e., dev automake now falls
> back to the previous one-second-timestamp behavior unless autom4te is
> known to be new enough (specifically, that it uses Time::HiRes).
> 
> Please confirm if possible ... --thanks, karl.

Thanks. I've tried, and after the update to
5c85c782ae63769cc8c0b56505f7b188009d, the
failures have disappeared.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)