Hi Bill - thanks much for the detailed and thought-out message.
Since the same source would
be compiled for multiple devices, it would be advantageous to compile
the source with multiple compilers within a single Makefile.am.
...
add new variables (`maude_CC', `maude_CXX',
The Solaris failure is because their date does not support the '--date'
or '-r' option.
As far as I can tell, the date command on Solaris 10 (cfarm210) and 11
(cfarm211) does not support any way to print a specified date value. So
I inserted a fallback to perl -e 'print scalar
gmtime($SOU
Does anyone have a BSD system (any flavor) I could get access to?
Alternatively, attached is my unreleased version of mdate-sh which tries
to handle SOURCE_DATE_EPOCH. It seems to work ok with GNU date. I copied
the BSD date command (date -u -r ...) from
https://reproducible-builds.org/docs/source
Hi Nick, Yang,
IFS=$' \t\n' is a bashism which is not supported in most other shells.
The original code is portable. This seems to have nothing to do with
the rest of your change, so why change it at all?
Indeed, I was going to make the same comment. I won't be installing that
part o
If you need to link against libraries that are not found by
@command{configure}, you can use @code{LDADD} to do so. This variable is
-used to specify additional objects or libraries to link with; it is
-inappropriate for specifying specific linker flags; you should use
-@code
Hi,
Subject: bug#78329: bash extraction of segment from end of string
returns full string
Thanks for the report, but why are you sending this to bug-automake?
It seems like bug-b...@gnu.org is the right list for this one ... --best, karl.
Hi Ross - I tried to again to reproduce your AC_RUN_LOG leftover after
autoreconf, following your original report at
https://lists.gnu.org/archive/html/automake/2025-02/msg00037.html
and followups over the last couple of months.
Downloaded intltool from https://launchpad.net/intltool/+download
a
-The '--test-name', '-log-file' and '--trs-file' options are mandatory.
+The '--test-name', '--log-file' and '--trs-file' options are mandatory.
Thanks Reuben. I installed it. -k
Sam, if your situation needs to remove .deps at make clean, how about:
clean-local:
rm -rf .deps
It does not seem plausible to me to change automake's behavior in this
regard at this late date. It would surely cause a lot of trouble in a
lot of packages. --best, karl.
Hi Ross,
I shall update to the final [autoconf] release
Have you had a chance to try this? I would like to get to the bottom of
this so I can make the release.
because intltool is already configured, being a tarball.
Your intltool link does not seem to provide any tarball.
[1] a
A patch to mdate-sh might take the form of checking (possibly only
when a command-line option is also specified) if $SOURCE_DATE_EPOCH
is set in the environment, and if so favoring that timestamp over
the mdate of its target file.
That sounds doable. Thanks. I don't think an extra
-# developer- defined test setup AM_TESTS_ENVIRONMENT (if any), and
+# developer-defined test setup AM_TESTS_ENVIRONMENT (if any), and
Thanks Reuben. I applied it. -k
I renamed find_file to find_file_with_opt
Thanks.
I would prefer to rename the original function to find_file_m4
I agree in the abstract, but it's not worth creating an incompatibility.
Look, the last argument *was* described:
Yes, I saw that, but a few words in the description wo
Is there a way to get more visibility into what autom4te is doing?
autom4te --help lists various options (at a glance: --verbose, --debug,
--trace=AM_TRY_LOG, who knows what else). I've never actually understood
autom4te in the slightest, sorry to say. Maybe best to bring it up on
bug-autoc...
Hi Eric and all,
eb> now questioning why Debian ever needed a patch to rip UPDATED out of
eb> the manual in the name of reproducibility.
Me too.
If the mtime isn't changed, then the original UPDATED should be
unchanged, and there's no problem.
If the mtime is intentionally changed by a patch or
Hi Ross - continuing on bug-automake from your report at
https://lists.gnu.org/archive/html/automake/2025-04/msg2.html.
(No reason to bother platform-testers with this.)
> I repeated my tests and rebuilds of existing source trees that have
> been configured with 1.70 still break for me
Hi Eric and all,
mdate-sh was older at the time 1.4.19
was cut; it has changed in the meantime
The only changes to mdate-sh in recent years have been trivialities
involving the help message and induced Emacs incompatibilities for the
Local Variables block. The actual code hasn't changed i
Hi Santiago - back on:
aclocal: error: too many loops
aclocal: Please contact .
at /usr/share/automake-1.16/Automake/Channels.pm line 655.
I still don't know how to improve the error message, but in response to
the same bug report with another package (#77395), I found that in the
p
Thanks for the patch, and sorry for the delayed reply. My concerns are:
1. Changing the meaning of the --libdir option so that it adds rather
than replaces. We have no way of knowing if existing projects rely on
that, but it's quite possible. A new option name is needed to avoid
breaking compatibi
at /usr/share/automake-1.17/Automake/Channels.pm line 658.
Automake::Channels::msg("automake", "", "too many loops")
Thanks for the report.
The full reproducer is this:
Thanks.
Is this issue known?
It was also reported for current Alpine, but not in a way I coul
Hi Nikolaos - thanks for the submission and the reversion :). I find
the existing text (and the companion suffix7.sh test) quite confusing,
but it does seem to be written as intended. So, closing.
Regarding the question you sent me separately, about still looking for
maintainers: most definitely.
Hi Eric and all - back on this report from 2015 (sorry):
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20831
This is a regression in behavior in upstream automake. It means
that any automake-generated file that is unpacked with timestamp skew
will now fail to build
Yes. I'm afra
Hi Javier - back in 2011 (!), you suggested switching to ustar as the
default tar format for Automake. Sorry for the absurdly late reply. This
has now been done for the upcoming automake-1.18; see discussion in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74847.
As I guess you know, both then and
Hi Pavel - back in 2014 (!), you suggested supporting python2 and python3
simultaneously: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=17811
Essentially by defining a new "python3" primary to sit alongside
"python".
Agreed that this is desirable in general. It's now being discussed in
https://d
Hi Florent - you sent in a report about automake gratuitously finding
install.sh in a parent directory back in 2015 (!). Sorry.
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19964
You probably have reasons to look in .. or ../.. (and I would be
quite interested to hear them, actually)
Back on this suggestion:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74847
What do you think about changing Automake's default tar format from v7
to ustar?
Given Bruno's experience, ok, let's try. I won't be surprised if
problems come out of the woodwork, but maybe it will be fi
Thanks for the report, Reuben. I'll mark it as confirmed+needs help, so
it can stay open and people looking for something stray to work on might
find it. Like you, I'm content for it to stay open until there is
further demand. --best, karl.
The attached patch assumes that
"no-dist-built-sources" is the right option name
Yes, good. I played around with the test some more for cleanliness, but
didn't touch your changes to the code. Hopefully "no-dist-built-sources"
now operates as intended. Pushed and closing ... thanks Bogdan.
I'm closing this for lack of information, but feel free to reply/reopen
or open a new issue if desired. --thanks, karl.
[I mailed this yesterday, but the bug has not been updated. Disturbing.
originally mailed on Date: Sun, 23 Feb 2025 13:35:17 -0800.
Trying again.]
Hi Giacomo - back on your report from last year (sorry):
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=73316
1. As you pointed out, TAR_O
I'm going to close this for lack of any apparent way forward, but feel
free to reply/reopen or open a new issue if desired. --thanks, karl.
Hi Giacomo - back on your report from last year (sorry):
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=73316
1. As you pointed out, TAR_OPTIONS is working fine from the command
line, but it doesn't work when written inside Makefile.am,
You need to add an "export" directive to t
Hi Maxim - I think so much depends on the details of a given project
that I lack ideas for something to do in general.
One possibility that occurs to me in your case is to turn your automake
conditional into a make conditional, instead of mixing them.
Another possibility might be to move the make
configure generated by autoreconf includes
this line:
AM_DEFAULT_VERBOSITY=0ac_config_headers="$ac_config_headers config.h"
Thanks for the report and proposed fix, Francis. I added Nick's suggested
m4_newline() to AM_SILENT_RULES in silent.m4.
I see in your kea configure.ac:
m4_ifd
I need to install automake-1.9 on macOS Sequoia 15.3.1
Automake 1.9 was released in 2004. I'll be surprised if it works on the
latest mac.
In any case, you'll need to replace config.sub, and perhaps other such
common files, with the latest versions, after unpacking. You can
download the lates
the three patches from the preceding mail are ready to commit.
Thanks very much for all your work (and explanations) on this, Bruno.
Committed. -k
Hi Kirill - thanks for the report and proposed fix.
export MSYS2_ARG_CONV_EXCL='-Tp'
Setting an environment variable seems fairly safe, since if an older
version of the compiler doesn't pay attention to it, at least the
problem will not become worse.
However, I'd like to hear from others who
GNU Automake will generate a broken Makefile when configuring if
some variables containing line breaks.
Thanks for the report. I'm not sure what Automake can do about it,
though. It's just doing what it's been told, seems to me?
Admittedly the error message is less than ideal, although th
Hi Santiago,
at /usr/share/automake-1.16/Automake/Channels.pm line 655.
The current version of Automake is 1.17. Hopefully you can try against
that. I seem to remember some sort of bug relating to that "too many
loops" error, but who knows.
apt-get source alpine
cd alpine-2.26+dfsg
>> Possibly automake can move from v7 to ustar.
Possibly. What's the advantage? --thanks, karl.
Hi Collin - looks fine to me. Applied. Thank you for updating the
timestamps and providing the ChangeLog entry. --happy hacking, karl.
>./configure PERL='/usr/bin/env perl'
>
> and it will substitute that into the scripts for you, but the configure
> script in Automake 1.17 exits with a fatal error if it determines that
> $PERL contains spaces. We should probably make this non fatal since the
> check i
Should we open a bug for this?
No need to open a separate bug. I can change AC_MSG_ERROR to
AC_MSG_WARN, and perhaps tweak the message a little. --thanks, karl.
Hi Maxim,
the Make conditionals would not work as I expected.
Since Automake rearranges things quite a lot when generating the
Makefile from Makefile.am, I'm not too surprised there can be problems.
I could give it another look to see if I
can distill some interesting points from t
Hi Maxim - thanks for the report and doing the research to find that old
answer. Do you have any ideas for a better solution? I can't think of
one. We can't change Automake syntax now. Nor does it seem maintainble
for automake to have special knowledge of all of make's builtin
conditionals and matc
without this being a factor 0 fails 0 errors, sorry for the false alarm :)
Thanks Jeff. Those are the kind of problems I like :). Closing ...
Hi Jeff,
automake: 1.17 "make -k check" (-j8) told me to email my test results
here so here they are
Thanks for the report. Looking at the log, the two failures both seem to
relate to the version of autoconf changing during the run, which seems
bizarre. I can't think of anything Automake
ments. I.e., it does not apply to a C<+=> assignment (except
when part of it is being done as a conditional C<=> assignment).
-This function will all run any hook registered with the C
+This function will run any hook registered with the C
function.
=cut
Running comma
Hi Giacomo - thanks for the report. Unfortunately, I (still) don't see a
good way for Automake can automatically deal with this problem. After
reading the various links in your message, it seems even less feasible.
Automatically switching to tar-pax if the current id is too large feels
like too bi
Hi Eric - I've just committed a change that I hope fixes the version
number problem. (See https://bugs.gnu.org/72157)
However, looking at your list of failures, I see that some of them are
still about *.dSYM, now relating to distclean. E.g.,
t/yacc-bison-skeleton-cxx.sh shows:
ERROR: files lef
Hi Dario - thanks for the report. I've made the changes below to try to
support the new four-part numeric version numbers, like 1.17.0.91 (which
is now the current dev version).
All the tests pass for me, so I hope it's also usable. I won't be
surprised if something is still messed up somewhere,
Hi Eric - thanks for the follow-up. I believe most or all of those
failures are because of a dumb automake version parsing problem that I
haven't fixed yet (there's never been a version like 1.16.0.90 before),
unrelated to the .dSYM patch.
BTW, I ran my make check with -j too. It's pretty unbearab
Hi Eric - I applied the patch from 72225, which hopefully also fixes
your report in 72852. Closing both, with fingers crossed. Thanks!! -k
Hi Eric,
Subject: bug#72852: Testsuite summary for GNU Automake 1.17 on
x86_64-apple-darwin20.6.0
Thanks for the report. It looks like Apple's compiler, or linker, or
something, is leaving new files, in fact a whole new directory, behind.
I didn't check all the failures, but the ones I l
> - $output_rules .= "check-am: all-am\n";
> + $output_rules .= "check-am: all-am";
> if (@check)
> {
> - pretty_print_rule ("\t\$(MAKE) \$(AM_MAKEFLAGS)", "\t ",
@check);
> + $output_rules .= " @check";
Looking again, the
Thanks much, Bogdan.
-recheck: all %CHECK_DEPS%
+recheck: all-am %CHECK_DEPS%
Do you have a grip on all-am? Looking at handle_all in bin/automake, I
admit I remain baffled as to what all those pieces of all-am are, and
why it's done as it is.
- $output_rules .= "check-am: all-am\n";
Thanks Bogdan! I will review as soon as I have a chance. --best, karl.
nb> there must be an expansion written somewhere in configure.ac
which is producing the problematic construct.
Thanks Nick.
Francis, can you show us your configure.ac please?
But at the same time, it is probably not a big deal to restore the
extra newline in Automake. But maybe
AM_DEFAULT_VERBOSITY=0ac_config_headers="$ac_config_headers config.h"
Thank you very much for the report and patch (which looks perfectly
reasonable at first blush). I am surprised there's no test for this so
that it would have been caught before the release. I'll look into it as
soon as I hav
Automake installed from the current master (commit
4e6eff3597649782def55fc1dfeeec92cec4b15e) is unusable:
Thanks for the report. Will look into it asap. Hopefully someone else
(Bogdan?) will beat me to it. --best, karl.
I've committed the changes below to help give more hints about the need
to run libtoolize. I ended up adding a new section to the manual and
referring to it from the alpha-NEWS and variable warning. It's in the
below patch as the new
@node Libtool library used but LIBTOOL is undefined
After maki
While I agree I can avoid this problem with the acinclude.m4
approach, I'm hesitant to do so because it's a corner case we don't
hit that often, I'd rather put my effort into a general fix for
everyone.
I understand. OTOH, I can say that putting Nick's m4 magic into your
acinclude.
slow every bootstrap for us (which we do frequently) to work around a
relatively rare issue.
Nick's solution of using acinclude.m4 seems ideal. But just in case: I
think you could also avoid the extra libtoolize calls by doing them only
if the automake --version is x.y.9*, i.e., a test rel
libtoolize: linking file `sntp/m4/libtool.m4'
Indeed, that seems like it should work, because the aclocal invocation
from autoreconf is looking into sntp/m4 (and /m4 too) and
finds other files there:
..
autoreconf: running: aclocal --verbose --verbose -I sntp/m4 -I sntp/libevent/m4
-I sntp/l
> But none of this is meant to suggest that there isn't actually some real
> change in aclocal behaviour which is causing the results you are seeing.
I've failed to find any regression. As I said, if I install 1.16.5 into
a test --prefix and run ntp's bootstrap with that prefix, it cannot
Hi Dave,
Why is it installing prerelease automake in a different prefix for
testing hasn't required also installing libtool to the same prefix
In general, I think it does. And always has. This is not new behavior,
as far as I can see.
(think back to your "baffled" comment)?
Indeed :
Hi Dave,
# wget https://davehart.net/ntp/test/ntp-4.2.8p18-vcs.tar.xz
# tar xf *p18-vcs*xz
# cd *vcs
# ./bootstrap
After more testing, I don't believe it is a regression. If I install
1.16.5 in its own prefix, say /tmp/am165, the ntp bootstrap fails in the
same way:
Makefile.am:16
Repro steps
Thanks. Evidently something must have changed in automake's libtool
support, but looking at the ChangeLog, I don't see it. I will look into
it ... --thanks, karl.
Hi Dave,
installed and installing the prerelease version to a prefix earlier on my
$PATH, not realizing I also needed to install libtool to the same prefix
Well, I'm glad that it's apparently not a "real" problem, but I'm rather
baffled. When I test an automake pretest, I don't do anythi
I've attached a patch that I think handles that
Thanks Collin. I installed it (with minor wording tweaks).
and the extra space you mentioned.
I had thought the extra space was useful rather than confusing,
indicating that a word had been omitted from the output. But I'm fine
with leavin
Here is a patch that allows the package maintainer to eliminate the
SKIPped test logs, thus making test-suite.log more useful: either
by running
make check IGNORE_SKIPPED_LOGS=1
or by defining in the Makefile (or Makefile.am):
IGNORE_SKIPPED_LOGS = 1
Thanks Bruno. I ins
When Paul fixed typos in various files a few days ago:
commit 1d35638b23e95fe6f41c828a3442f6d7f242f4c4
Author: Paul Eggert
AuthorDate: Fri Jun 7 08:41:45 2024 -0700
maint: spelling and whitespace fixes
He noted:
* t/instdir-ltlib.sh: Fix misspellings of macro names.
Hi Yves - back in 2017 you sent a patch to sort keys in automake:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25629
Attached is a patch that I believe fixes any remaining uses of
unsorted keys.
I've now applied this, with the exception of
a) the cases that had already been done in t
Is bug-automake working now?
Do color-tests2.sh and color-tests2-w.sh both write to the same
directory and, thus, running in parallel may have caused them to be
writing to the same file(s) at the same time?
Every test runs in its own t/*.dir/ directory. The ct2-w.sh test
sources the ct2.sh shell script, but it's
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
somewher
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
lossage
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 th
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 g
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. Wou
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
support
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 h
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 https:
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
1 - 100 of 473 matches
Mail list logo
