Hi Erik,
* color-tests2.sh and color-tests2-w.sh fail -- logs attached.
Is this with the old make 3.81 from the system, or the new make you
compiled? What is in the "stdout" file in t/color-tests2.dir/stdout?
And, are these the only two tests that fail in the entire suite?
What I see in the
* fine on the tests that failed previously because of macOS default
make having only second resolution
Great! Thanks much for the instant testing.
* color-tests2.sh and color-tests2-w.sh fail -- logs attached.
I had tweaked some of the color stuff, so I must have messed up
Hi Erik and all - I (finally) made the change below to have automake
test for a make that doesn't support subsecond mtimes even when the rest
of the system is ok, as you noted happens with the make-3.81 shipped by
macOS.
I installed make-3.8.1 on my Rocky 9 system, but it did not cause the
I pushed Bogdan's patches. Listing several functions to look for in
(lib)objc in multiple places doesn't seem ideal, but factoring that out
doesn't seem easy either.
strip -x: no problem.
The general issue:
The AC_PROG_OBJCXX macro already tries to compile a trivial program (of
course), but the
Hi Mark,
> ... correct the
> documentation and usage messages to describe it accurately, with a
> historical note in the manual explaining the long-standing error
I finally had a chance to apply this patch. Thank you for your careful
work! I just tweaked a few words in
Thanks for the Vala doc patch, Reuben. Installed and closing. --best, karl.
so you have to give it all the source files at once,
Wow.
I guess it is worth documenting this limitation of the current Vala
support. If you agree with my reasoning above, then I will prepare a
documentation patch based on it.
All I know about Vala is what you've written, but
Hi Mark - thanks for the report.
it seems to me that the least bad approach is to correct the
documentation and usage messages to describe it accurately, with a
historical note in the manual explaining the long-standing error in
previous versions of the documentation.
I agree.
Reuben, any chance you can whomp up a test for this patch?
I don't see a problem with the change, but it's always better to add a
test against future regressions, etc. --thanks, karl.
Attached, an updated patch that passes the tests. It uses GNU Make
functionality, but this is already required by the Vala support.
Thanks Ruben. I will peruse as soon as I have a chance, if no one else
gets there first ... -k
Per https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649576.html
this was fixed in https://bugs.gnu.org/46744. As I understand it.
Closing.
so whether it is
@NATIVE_FALSE@install-exec-local:
@NATIVE_FALSE@uninstall-local:
or
@NATIVE_FALSE@uninstall-local:
@NATIVE_FALSE@install-exec-local:
depends on some hash table traversal or what.
Thanks for the report. Any chance of a Makefile.am that can reproduce
the
The output I got from this and dist-no-built-sources.log is rather
interesting. As it looks, the test is indeed broken from the beginning.
Thank you very much, Jens. We'll deal with this asap. Your original
analysis that we simply don't recognize the right option name is looking
correct
Hi Jens - thanks for the report.
Nevertheless I think there is something wrong here.
Quite likely. Can you please send an example tree that shows the failure?
'DIST_BUILT_SOURCES' => !! option 'dist-built-sources',
Hmm. I had a vague impression that the "no-" was automatically
Attaching a simple patch
Thanks Bogdan! I pushed those changes.
Marcel, if you're able to try testing from the repo, that would be
great. Else it hopefully won't be too long before the next pretest
(or, even more optimistically, the next release). -karl
Hi Peter,
The problem seems to be that both $(TESTS) and check_LIBRARIES depend on
libfoo.a and trigger compilation of foo.cc.
Thanks much for the report and analysis. What you wrote looks sensible
to me.
My understanding of parallel make is a bit hazy,
Me too :(. If anyone else
parse1.yy:30:7: error: conflicting declaration of 'void yyerror(const
char*)' with 'C' linkage
parse1.yy:7:6: note: previous declaration with 'C++' linkage
Thanks much for the careful and complete report.
I think this is another manifestation of what Bogdan fixed in other
cases in
Erik, I think all the automake test problems you reported here have been
resolved (thanks to your excellent debugging). So closing. Leaving
#68808 open until Zack or I have a chance to look into testing of make
for the subsecond mtimes. Thanks again! -k
Hi Arnaud - back on this bug from last April, I guess I just don't think
it's the job of mkinstalldirs to follow symlinks. It feels like too big
a change in behavior. I think the real bug here lies in whatever
created the broken symlink in the first place.
So I'm going to close this one. All the
I'm going to close this bug about the random test failures, partly fixed
in #67670 and partly still open in #68808, but nothing to do
here. --thanks, karl.
Those square brackets are M4 quotes to prevent M4 from expanding
$* and $2 itself.
Ah, right. Of course. Good!
The $[*] especially confused me. Just looks so perfectly like an array
reference of some strange kind :). I think it would be a tiny bit
clearer to use $[]*? Or am I missing
(Off-topic for the original bug, but for the sake of public discussion ...)
Hi Zack,
It is absolutely not *supposed* to be using shell arrays.
I guess it's not an array. It's the square bracket syntax that confuses
me. A couple of examples from the fn in sanity.m4:
test "$[*]" != "X
Hi Erik - following up on your final comment in #68119:
P.P.S. It still needs
export am_cv_sleep_fractional_seconds=false
to correctly run the tests on macOS. Without that, 75-90 tests fail.
Maybe we can try to figure out why the code that tries to automatically
discern
When I run âmake checkâ, it fails after
passing t/pm/Wrap.pl with the following error:
sh: >&3 : bad file descriptor
tap-driver.sh: fatal: I/O or internal error
Thanks for trying, though sorry to see that result. It's not clear to me
what test is failing or what the
Hi Erik - yay for near-success :).
case $(echo "$files" | wc -l | sed 's/^ *//') in 4|6) ;; *) false;; esac
I went with that sed.
because "wc -l" prints some spaces in front of the number (at least
on macOS).
I'm surprised this has not been seen already. But fine.
At least it's
The attached patch fixes the tests for Python 3.12
Thank you Bogdan! Looks good to me. Installed.
(and, hopefully later ones),
Maybe until Python 3.12.2, anyway. --thanks, karl.
I was able to bootstrap, configure, build and install
automake-1.16j.
Great!
Is there any other testing I should do?
If you're up for it, you could run make -j8 check (or -jwhatever) just
to see if other tests fail. (It will take several hours to run without
the -j, although
Hi Erik - thanks for the continued testing.
Hi, Karl. I get an error on "make" because there is no "makeinfo"
command on macOS.
Well, since you've come this far, you could try installing the texinfo
package, if you have Perl.
Or perhaps it would be enough to
touch doc/automake.info
Hi Erik,
FAIL: t/aclocal-deleted-header-aclocal-amflags
FAIL: t/aclocal-deleted-header
I'm not sure, but I think the idea of those tests, and others, is that
after making the various changes to the configure setup, running make
should suffice to rebuild everything. Because that's what is
The email address for the OP bounced. So closing this one.
Hi Matt - back in 2015
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19692, sorry for the
delayed reply) you reported that your system failed the rm -f test.
For the next automake release, we've removed this test and tried to
accept any rm. (More info: https://bugs.gnu.org/10828.)
If you have
Hi Jarkko - back in 2015
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22074, sorry for the
delayed reply) you reported that your system failed the rm -f test.
For the next automake release, we've removed this test and tried to
accept any rm. (More info: https://bugs.gnu.org/10828.)
If you
Hi Bart - back in 2016
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23563, sorry for the
delayed reply) you reported that your system failed the rm -f test.
For the next automake release, we've removed this test and tried to
accept any rm. (More info: https://bugs.gnu.org/10828.)
If you have
I changed the pretest version to 1.16.90. Closing.
I installed Bogdan's version of Stefano's patch from #54412.
Fingers crossed. -k
there is nothing requiring or restricting the current version behavior
other than "it's always been this way".
True.
but that doesn't mean it's better.
No way to know what release or test scripts might be relying on the
current convention. Changing for the sake of change doesn't
Carl - sorry, you'll need to adjust your script. Automake and other
packages have used letters for pretests for decades, and it's not
plausible to change now.
Also, I have the impression that other packages use random git hexids in
their pretest releases, which aren't numeric either. -k
FYI, macOS has an old bison (version 2.3 from 2006).
I'm not sure if automake theoretically support bison going back that
far, but I'm not going to worry about it since many errors disappear
with the new bison. Thanks for thinking of that.
In both aclocal-deleted-header.sh and
Using am_cv_sleep_fractional_seconds=false dropped it to 7-11 tests failing.
Erik, thanks for all the trials and detailed analysis.
Nothing is immediately clear to me either :(, but I'll take a look. -k
It seems to work. 'make check -j16' goes through and since it seemed to
be of a random nature previously I ran the individual test repeatedly
and it passed every time.
Thanks for confirming, Peter. Myriad other problems have been reported,
so it's nice to have one that actually got
92 tests fail on 1.16j
Thanks for trying, though a sad result. I have a hunch that a lot of the
failures are timing issues. Although Automake thinks your system
"should" work with a 1-millisecond sleep at various points (I gather
you're already using autoconf-2.72), maybe there are problems
/usr/bin/lex --version
and that command reads from standard input:
Thanks Bruno. I installed the patch.
As for the other (non-ignored) failures, here and in your other reports
today ... I can't get far with such system-dependent failures. Any
chance you have time to delve into them? I
Hi Erik - thanks for the follow-up. Now I understand. You were testing
automake-1.16.5. But you sent it so soon after we released a pretest, I
didn't notice, and thought you were testing the pretest :).
These test failures (among lots of other things) are supposedly fixed in
the current sources.
- does not understand the option '--best', only '-1' ... '-9'.
- understands the options '-1' ... '-9' only when compressing, not when
Seems a rather unnecessary incompatibility that some system decided not
to support --best in gzip, when it has been available for those same 30
years. Oh
FAIL: t/python-prefix
Log file is attached.
I think it is the same issue as reported at
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64837 .
Thanks for the report. I hope Mike or Bogdan can look at it. I have
trouble discerning fixes for anything Python-related. -k
Subject: [GNU automake 1.16.5] test-suite 45 tests failed
Clean install of macOS Sonoma 14.2.1 on MacBook Pro M3 max
Thanks for the report, but it seems like something in the environment is
causing trouble. For example, one of the failing tests is
dist-vs-built-sources.sh:
gcc
I get one failure (t/nodef)
Hi Peter - I hope this random timing bug is fixed now. If you're able to
test from the automake source tree
(https://savannah.gnu.org/projects/automake/), that would be great.
Else the next pretest should be coming along soon. --thanks, karl.
I ran `make check` for this release on Fedora-rawhide and got random
failures. Multiple runs seem to show different failures on all arches
Hi Fredric - I hope this random timing bug is fixed now. If you're able
to try testing from the automake source tree
Closing this since there's nothing left to do on the automake side.
(Someone new volunteered to take over libtool, BTW, but I see no changes
in the maintainers file as yet. Not sure where that stands.) --best, karl.
> help2man: can't get `--help' info from bin/automake
> Try `--no-discard-stderr' if option outputs to stderr
Regarding automake's running of help2man. I forgot that this is ok
because automake (doc/local.mk) includes a copy of the help2man script
itself in its distribution,
$output =~ s/^((#.*)?\n)*\K/.POSIX:\n\n/;
Solaris 10 'perl --version' says it's Perl v5.8.4. v5.8.4 is dated
2004 but \K was added in v5.10
I simply removed the \K, since its only purpose is to optimize use of $&
(matched text), but we aren't using $& with this regexp, so far
Hi Frederic - (switching to bug-automake for tracking)
https://lists.gnu.org/archive/html/automake/2023-12/msg00034.html
I ran `make check` for this release on Fedora-rawhide and got random
failures. Multiple runs seem to show different failures on all arches
Thanks for the
Hi Peter - thanks for trying the automake pretest.
I get one failure (t/nodef)
I suspect a timing problem, since I can't fathom any reason why that
particular test would fail on your system specifically. (The test
basically just runs a minimal automake twice.)
with autoconf 2.71.
Here's line 8135:
$output =~ s/^((#.*)?\n)*\K/.POSIX:\n\n/;
Ah. I'll get rid of the \K, once I remember/look up what it does :).
(Jacob, if you have any advice, that would be great.)
A simple fix would be for Automake to require Perl 5.10;
Nah, we shouldn't require a jump in
Hi Paul,
help2man: can't get `--help' info from bin/automake
Try `--no-discard-stderr' if option outputs to stderr
So, the obvious question is, why can't help2man run bin/automake?
Clearly it works on other systems, and it doesn't seem like this should
be especially system-dependent. Can
Patch attached.
Looks just fine. Thanks Reuben. I installed it. Closing ...
--all the best, karl.
partially related to how Automake is calling libtool from the
build rules (it is missing the --tag option),
I added the tags to automake as previously posted here.
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=67539)
no tag defined for Objective C[1] (presumably it would be
Mike wrote me separately to say the problem eventually fixed itself for
no evident reason :(. Maybe related to our general timing issue?
Anyway, closing. --thanks, karl.
The manual currently says: "You should never explicitly mention the
intermediate (C or C++) file in any `SOURCES' variable; only list
the source file."
I don't know the code here, and this probably wasn't the question, but I
think the manual's statement about "any `SOURCES'
nobase-python: running python -V
Python 3.12.0
...
ModuleNotFoundError: No module named 'imp'
Looks like the failing tests are all Python-related, at least several
with the above error. I don't think Python 3.12 was even released at the
time of automake 1.16.5. I don't know what
Any chance that one of you could write a patch for the manual to explain
whatever needs to be explained (better)? --thanks, karl.
(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
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
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
Hi Dennis,
libtool: compile: unable to infer tagged configuration
Thanks for the report.
As you surmise, apparently this needs to be reported to
libtool. (Although afaik libtool is currently unmaintained, so I don't
know when or if anything will get fixed.) At least, I have no idea what
to
Hi Bruno,
This is with Automake 1.16.5 and Autoconf 2.71 on an ext4 file system.
[...]
When I add an 'rm -rf autom4te.cache' command before 'automake -a -c',
the failures disappear.
FWIW, in the Automake development sources, there is now a test to see if
autom4te is the new
Hi Quinn,
> Automake seems to be aware of $(@D) and $(@F), but not the others.
Thanks for the report. This was fixed not long ago, and will be in the
next release. The prior report, for the record:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=9587
All the best,
Karl
> And the patch against Automake attached now, sorry for the delay.
https://lists.gnu.org/archive/html/automake-patches/2016-03/msg0.html
In the better-late-than-never department: after eight years, I've
finally applied this patch to make Automake's default ARFLAGS be cru
instead of
Thanks Vincent. Closing.
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
Just to close this out: Bogdan worked up a patch to avoid the
fractional-second timestamps unless the new (current autoconf
development) autom4te is in used. Here is the basic change:
https://git.savannah.gnu.org/cgit/automake.git/commit/?id=b6fa73115d094c8d0da1d6759b6e7c7fca1f8a07
(also appended
automake: Please contact .
at /opt/local/share/automake-1.16/Automake/Channels.pm line 655.
Automake::Channels::msg("automake", "", "undefined condition
Thanks for the report. I (or someone else ... Bogdan?) will look into it
as soon as we have a chance.
Looking at the
> Indeed, these are random failures.
Closing per https://bugs.gnu.org/64756. Thanks.
I installed your patch (and added a tiny test case). Thanks Vincent!
Closing this bug (finally ...). -k
remake-after-aclocal-m4
is one of the two tests that fail.
I've attached the t/remake-after-aclocal-m4.log file.
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
This patch is from https://bugs.gnu.org/55025.
Thanks Vincent!
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
WDYT of cutting new `automake` that includes this fix? Then projects
could start cutting release tarballs that Just Work for such systems.
Agreed we need to make a new automake release asap, but unfortunately
the code is not ready. Releasing it would cause more problems than it
would
With automake master, on an Ubuntu 22.04 system (with Python 3.10),
I don't believe anyone has tried Automake with Python 3.10 before. Mike
and Bogdan put in quite a bit of work getting the current tests to work
with other versions of Python. Evidently every Python version does new
and
The various test-suite.log files show different test failures each
Yes. Painful. I believe this is due to a timing problem with autom4te,
exposed by Automake using fractional second sleeps according to what the
filesystem supports. It is fixed in the autoconf repository but hasn't
been
Hi Bruno,
GNU Automake already emits the '.SUFFIXES:' line. To optimize things
for GNU make, it should also emit the remaining part.
Ok. I just hope those weird-looking %:: rules do not cause trouble with
other makes. I guess we'll find out.
The fnoc test also failed due to the new
tmpname=`mktemp $(distdir)/dist.XX`
I don't think we can safely assume mktemp in automake rules.
tardir=$(distdir) && $(am__tar) > $(distdir)-$RANDOM.tar 2>$(distdir).err
That was my idea ($$ instead of $RANDOM). Certainly simple, but I agree
Nick's idea is cleaner:
>
Hi Dimitrios, Bogdan - back on this bug from 2015 (sorry):
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19614
Bogdan sent a patch that splits the tar and compress into separate
invocations. It seems basically good to me, but the dist-formats test
fails because it builds multiple archive
I could distribute just the .texi.in file and still get
autoreconf/automake/packaging to work. Right now, I get an error
about a missing .texi file
I thought Mike's fix (-e ... /dev/null) should already have fixed that?
Well, in any case, it's not bad to check for the .texi.in, so
I meant to include the patch I actually applied.
commit 5c85a9d31830a61facc298fa7d7d82f5651f1a6c
Author: Bogdan
AuthorDate: Thu Jul 13 15:32:34 2023 -0700
texi: assume .texi.in generates .texi.
This change refines the fix for https://bugs.gnu.org/54063.
* bin/automake.in
Bogdan, Pat, Gavin, all - back on this bug:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54063
Subject: bug#54063: - special case] Try .texi.in when .texi missing
Bogdan - the basic idea of your patch seemed fine, to use .texi.in when
.texi is missing.
After investigating the behavior
Hi - you have each reported Automake test failures on Solaris.
I've just pushed a fix from Bogdan (thanks Bogdan!) for some of these,
which (sometimes with other fixes already made) closes some bugs.
Bogdan explains the details of the latest:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45205#13
Mathieu and all - back on this report from 2018:
https://bugs.gnu.org/30556.
Mike (Frysinger) and Bogdan both made various patches that together
have, I think, fixed all these issues. Thanks x 2 :).
Here is the patch from Bogdan that I've just pushed to finish it.
Closing, with fingers crossed.
Hi Akim (hope all is well with you) and all,
Back on your report https://bugs.gnu.org/24507 from a mere seven years ago ...
> $ cat Makefile.am
> noinst_PYTHON = foo.py
> python_PYTHON = bar.py
...
> $ make uninstall-nodist_vcsn_tools_pythonPYTHON
> make: Entering
Back on this bug report from Nick in 2011 (thanks/sorry):
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=9587
bd> The attached patch allows the following symbols not to cause
Automake errors about non-POSIX variables (and updates the test):
$(@F) $(%F) $(?F)
Hi Dimitrios and all,
Back on this bug from 2015 and earlier (yikes, sorry):
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19615
TAR_OPTIONS = --owner=0 --group=0
I expected that something like this would be the default though.
I agree it would be desirable, in theory. But we can't
bd> My last patch for now, this time for
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20077
Thanks Bogdan, but $(shell) is a GNU make extension. It can't be used in
Automake's generated Makefile[.in]s.
mf> GNU Make supports:
mf> am__v_P_$(V) = $(am__v_P_$(AM_DEFAULT_VERBOSITY))
Hi Sebastian,
Currently, the "Name" section of the automake man
I just committed a change to set the Name section, as you suggested.
We'll now have (based on the --help message):
aclocal - Generate aclocal.m4 by scanning configure.ac
automake - Generate Makefile.in files for configure from
See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49901 for an
explanation. It's partially the macro itself that is buggy:
Indeed. I'm merging these bugs, although there is only a little that can
be done on the automake side, as far as I can see. --thanks, karl.
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
Thanks for the report.
The glibc installing process is calling
./scripts/mkinstalldirs [..]/lib64
which failed to mkdir -p it.
With literal brackets? I don't understand.
+ if test -L "$@"; then
+echo "mkdir -p -- \"\$(realpath $*)\""
Neither test -L nor (especially)
But anyway, patch for the Perl path attached.
Thanks. Your method seems as good as any to me.
I thought about using
'grep -q' and checking the exit code, but maybe this version is more
portable.
Indeed, grep -q is not portable. It's necessary to >/dev/null instead.
--thanks
Thanks for the report, Dan, and for looking into this, Bogdan.
#!User bins/perl
Apart from anything else, this cannot be solved. Shebang lines do not
support quoting.
Thus I think what we should do is have configure give a better error
message when the Perl path contains whitespace,
1 - 100 of 354 matches
Mail list logo
