Hi automakers,
I think I've found a race condition with 'make recheck' that results in
a source file being compiled twice in parallel and resulting in a
failure such as
mv: cannot stat '.deps/foo.Tpo': No such file or directory
In my trimmed down example my Makefile.am looks like:
lib_LIBRA
On 30/1/24 22:46, Erik A Johnson wrote:
(Why, then, does Apple continue to include 3.81 in the software 18 years later?
Beyond me.)
Probably because 3.81 was the last version released under GPLv2 or later
and IIRC Apple avoids shipping things that are licensed with GPLv3.
Cheers,
Peter
Hi Karl,
On 27/12/23 08:38, Karl Berry wrote:
I get one failure (t/nodef)
Hi Peter - I hope this random timing bug is fixed now.
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 e
Hi Karl,
On 20/12/23 10:09, Karl Berry wrote:
Could you try running the test on its own?
make VERBOSE=1 check TESTS=t/nodef.sh keep_testdirs=yes
I ran it ten times and it succeeded 70% of the runs, so seems quite
random in line with being due to the timing issue.
Peter
Hi both,
On 1/1/23 05:20, Bogdan wrote:
Karl Berry , Sat Dec 31 2022 03:30:42 GMT+0100
(Central European Standard Time)
Hi Bogdan,
Someone reported a bug for this, so I simply gave it a try.
Thank you! I didn't realize you were working on some of the old bugs.
That is great!
:)
To
Hi Mike,
On 25/1/22 16:24, Mike Frysinger wrote:
On 19 Jan 2022 18:32, Peter Johansson wrote:
On 19/1/22 18:10, Mike Frysinger wrote:
assuming it still fails with Automake 1.16 ...
I'll test when I'm out of this semi-lockdown and have access to a
computer with more CPUs.
can y
Hi Mike,
On 19/1/22 18:10, Mike Frysinger wrote:
retitle 17614 parallel compilation fails: mv:
yat/statistics/.deps/Percentiler.Tpo and yat/statistics/.deps/Percentiler.Tpo
are the same file
tag 17614 = moreinfo
thankyou
On Wed, 28 May 2014 14:52:21 +1000, Peter Johansson wrote:
I have a
Hi Mike,
On 11/12/21 15:14, Mike Frysinger wrote:
On 11 Dec 2021 09:33, Peter Johansson wrote:
On 10/12/21 15:47, Mike Frysinger wrote:
if it's dropped, i'm not sure how users are supposed to fix things.
the error message says to install GNU coreutils, but if GNU coreutils
uses au
Hi Mike,
On 10/12/21 15:47, Mike Frysinger wrote:
if it's dropped, i'm not sure how users are supposed to fix things.
the error message says to install GNU coreutils, but if GNU coreutils
uses automake and presents the same error ...
FWIW, automake is not needed to build and install GNU coreut
Hi Kasper,
I leave to the maintainers to comment on the suggestion, but in the
meantime...
On 1/7/21 1:01 pm, Kasper k wrote:
Hello automake devs,
In script based testsuites
(https://www.gnu.org/software/automake/manual/html_node/Scripts_002dbased-Testsuites.html#Scripts_002dbased-Testsuite
On 25/3/21 8:24 pm, Дилян Палаузов wrote:
• Please adjust Automake on “make install” to do (per default or with
an option) atomic install of files, even when libtool is involved: the
file is moved to a temporary destination first, and then rename(2)d, or
the source is moved to the destination,
Hi Ruben and Mathieu,
On 4/22/2018 1:13 AM, Mathieu Lirzin wrote:
Hello Reuben,
Reuben Thomas writes:
In the manual, we are given the following pattern for using help2man
without breaking make distcheck:
foo.1: foo.c $(top_srcdir)/configure.ac
$(MAKE) $(AM_MAKEFLAGS) foo$(EXEEXT)
help2man
On 05/19/2016 09:04 AM, Mathieu Lirzin wrote:
Another common use for "expected failure" is to write tests to check
>that error conditions arise as expected, for example, by checking that
>a program raises an error when given invalid input.
I agree that XFAIL can be ambiguous, however I think t
On 11/19/2015 06:19 PM, Joakim Tjernlund wrote:
hmm, I see the problem.
How do I change Makefile.am, with minimal effort as we have alot of them?
Tried
bin_PROGRAMS += emxp_hw_bl/emxp_hw_bl
but that gives me:
ne/emxp_ss/emxp_hw_bl/Makefile.inc:14: warning: variable 'emxp_hw_bl_SOURCES'
is
Hi Joakim,
On 11/19/2015 11:15 AM, Joakim Tjernlund wrote:
automake>= 1.13 (did not test lower than that) dies during make with:
CCLD emxp_cm_bl_shell
rm: cannot remove 'emxp_cm_bl': Is a directory
Makefile:1070: recipe for target 'emxp_cm_bl' failed
This happens if you have the same
;***"
@echo "***"
@echo "I want this to be called before the check"
@echo "***"
@echo "***"
Cheers,
Peter
--
Peter Johansson
a bad
habit?
A fix could be to let distcheck not work in $(distdir) but instead
create 'tmp_/$(distdir)', builddir 'tmp_/$(distdir)/$(builddir)', and
installdir 'tmp_/$(distdir)/inst_' which would hide the development
files from the distcheck. What do you think?
Thanks,
Peter
--
Peter Johansson
On 05/28/2014 02:52 PM, Peter Johansson wrote:
Hi,
I have a project with a libtool archive built from many source files.
When I build with 'make -j40' I get error message
mv: `yat/statistics/.deps/Percentiler.Tpo' and
`yat/statistics/.deps/Percentiler.Plo' are t
.lo] Error 1
Looks like some kind of race problem, but I cannot see anything wrong in
the Makefile. Is this a known problem? If not let me know what would be
useful.
The Makefile is generated with Automake 1.14
Thanks,
Peter
--
Peter Johansson
included in
config.h.in.
Sorry about the confusion.
Cheers,
Peter
--
Peter Johansson
[adding bug-automake]
Hi infirit,
On 02/02/14 12:25, infirit wrote:
Hi,
So for a project we wanted to make the tarball different from from the
package name. So we updated AC_INIT and added the tarname and indeed
now the tarball generated changes.
However, we noticed that now the $PACKAGE vari
On 12/06/2013 08:49 AM, Eric Blake wrote:
Why not? 1.13 is almost one year old now...
Believe it or not, some people still like to make their project work
with out-of-the-box tools.
+1
--
Peter Johansson
Hi,
This is probably already fixed with the version scheme and everything,
but wanted to report it just in case. I updated from from automake 1.13
to 1.13.3 and after having modified an Makefile.am, Automake complained
about version mismatch. I suspect aclocal.m4 was created with aclocal
1.13
x27;s namespace, 'AM_', comes to mind: {AM_RELDIR}.
cheers,
--
Peter Johansson
ould be removed with no loss:
2.0 -> 2.0
2.0.1 -> 2.1
2.0.2 -> 2.2
2.1 -> 3.0
3.0 -> 4.0
3.0.1 -> 4.1
4.0 -> 5.0
or just keep the scheme as is
1.14
1.14.1
1.14.2
1.15
1.16
1.16.1
1.17
Cheers,
Peter
--
Peter Johansson
On 01/12/2013 04:45 AM, Stefano Lattarini wrote:
As a rule of thumb on when to remove a macro - I would personally like
> being able to write a configure script that works on both RHEL 5 (or
> CentOS 5) (autoconf 2.59, automake 1.9.6) as well as rawhide (eventually
> automake 1.14 and beyond),
Hi Stefano,
On 01/08/2013 08:18 AM, Stefano Lattarini wrote:
Actually no, the change tend to be much more extensive (as they've been
between 1.12 and 1.13, not always smoothly or pleasantly). Maybe, to make
this clear, we should name release a 2.0 version instead of a 1.14?
No need, IMHO. Perha
y
understanding going from 1.13 to 1.14 is similar to go from Autoconf
2.68 to 2.69.
Cheers,
Peter
--
Peter Johansson
On 9/24/12 6:18 PM, Hib Eris wrote:
Hi Peter,
Thanks for looking into this.
On Mon, Sep 24, 2012 at 8:29 AM, Peter Johansson wrote:
I have the setup you describe, and I have not encountered the problem you
describe.
I have AC_CONFIG_HEADERS([config.h lib/config_public.h])
and there is no
On 09/24/2012 01:57 AM, Hib Eris wrote:
Hi,
With AC_CONFIG_HEADERS(config.h subdir/myconfig.h) in configure.ac,
automake generates a target to build config.h.in with autoheader in
Makefile.in (as expected),
but it also generates a target in subdir/Makefile.in to build
subdir/myconfig.h.in which
[CC coreutils this is
http://lists.gnu.org/archive/html/bug-automake/2012-08/msg1.html]
On 09/14/2012 07:29 PM, didi wrote:
You can already do this. You can, e.g., install packages with
>
> make install MKDIR_P="mkdir -p -m 700"
Unfortunately this doesn't seem to work properly, as the p
On 08/21/2012 02:46 PM, Jason Eisner wrote:
Better idea:
Have default 644 for files and 755 for directories, but let the user
override this by explicitly specifying any of
* the desired file permissions
* the desired directory permissions for newly created directories
* the desired group owner
Hi Stefano,
On 7/27/12 7:08 PM, Stefano Lattarini wrote:
severity 12064 minor
thanks
On 07/27/2012 04:12 AM, Peter Johansson wrote:
Hi automakers,
I was about to make a release when I discovered that distcheck suddenly didn't
work
anymore. The distclean rule failed with
Making dist
Hi automakers,
I was about to make a release when I discovered that distcheck suddenly
didn't work anymore. The distclean rule failed with
Making distclean in doc
make[2]: Entering directory
`/home/peterJo/projects/software/yat-0.8.x/yat-0.8.2/_build/doc'
Makefile:498: ../yat/classifier/doxyg
failed due to compilation problems or at least tests
that failed last time they were run.
Please find a script attached illustrating the behavior.
This is with automake 1.12.
Cheers,
Peter
--
Peter Johansson
recheck.sh
Description: Bourne shell script
Hi Stefano,
Sorry about this late reply.
On 04/28/2012 12:34 AM, Stefano Lattarini wrote:
--- a/bootstrap
+++ b/bootstrap
@@ -77,6 +77,8 @@ dosubst ()
{
rm -f $2
in=`echo $1 | sed 's,^.*/,,'`
+ current_year=`date +%Y`&& test -n "$current_year" \
+|| { echo "$me: cannot get current
Hello,
Just a tiny nit. After installing the new version (1.12) of automake I
noticed that 'automake --version' outputs:
automake (GNU automake) 1.12
Copyright (C) 2011 Free Software Foundation, Inc.
whereas I expected it to say 'Copyright (C) 2012...'
Cheers,
Peter
On 1/8/12 7:56 AM, Stefano Lattarini wrote:
The attached patch should take care of the problem. Tested using
this script in PATH as the `ln' program:
Hi Stefano,
I'm just curious if there is a reason not to use AC_PROG_LN_S as
provided by Autoconf. I thought one could call that macro in Au
Hello automakers,
I have a non-recursive Makefile.am but keep the tests in sub-directory named
test. Surprisingly distcheck fails for me with this set up, which to me
seems to be caused by some VPATH issue.
Below is a trimmed down test case that fails for me with
make check-TESTS
make[2]: *** N
Hi Bruno,
On 7/8/11 5:24 PM, Bruno Haible wrote:
+If you are using GNU @code{automake} 1.10 or newer, it is even easier:
+Add the line
+
+@example
+ACLOCAL_AMFLAGS = --install -I m4
+@end example
+
+@noindent
+to your top level @file{Makefile.am}, and run @samp{aclocal --install -I m4}.
+This wi
Hello Stefano,
On 3/19/11 8:36 AM, Stefano Lattarini wrote:
On Saturday 05 February 2011, Peter Johansson wrote:
I find the last sentence a bit strange because to me that sounds like
Automake suggests that packagers should install macro files in a
hard-coded directory not relative to $(prefix
Hello,
In the manual,
http://sources.redhat.com/automake/automake.html#Invoking-aclocal,
I read about the `--print-ac-dir' option:
Prints the name of the directory that |
|aclocal will search to find third-party .m4 files. When this option is
given, normal processing is suppressed. This optio
Hello,
I experience failure on cscope.test and instspc.test in the latest git
version of automake. I attached the test-suite.log (gzipped). AFAICS, it
seems cscope fails because I have fortran compiler. If that's the case I
suppose the test should be skipped. Unfortunately, I don't know how to
Hi Ludo,
Ludovic Courtès wrote:
The ‘configure.ac’ file:
http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=configure.ac;h=476a73c75e5f415af7b60b22166f61458b19bc38;hb=e17b58c22e50a515a1c14bd4f93372bf3df75b9a
This doesn't help you much, but if I set
AC_INIT([GNU Guile], [1.0], [em..
Hello Ludo,
Ludovic Courtès wrote:
Hello,
I recently changed Guile so that PACKAGE is “GNU Guile” (instead of
“guile”), while PACKAGE_TARNAME remains “guile”.
I wonder how you did that. Could you please post your AC_INIT line, and
AM_INIT_AUTOMAKE if you set PACKAGE the old school way.
T
Hello,
I included a file in my Makefile.am, but then I decided it was not
useful anymore so I removed the include statement and deleted the file.
That resulted in a broken Makefile, and running `make all' resulted in:
make: *** No rule to make target `aminclude.am', needed by
`Makefile.in'.
Hi,
I experience a failure of instspc.test in automake 1.11 test suite.
Please find the test-suite.log (gzipped) attached.
I use:
autoconf (GNU Autoconf) 2.64
GNU Make 3.80
GNU bash, version 2.05b.0(1)-release (powerpc-apple-darwin8.0)
Thanks,
Peter
test-suite.log.gz
Description: GNU Zip
n pdf here
http://aegis.sourceforge.net/auug97.pdf
Cheers,
Peter
--
Peter Johansson
svndigest maintainer, http://dev.thep.lu.se/svndigest
yat maintainer, http://dev.thep.lu.se/yat
<< "Hello World\n";
return 0;
}
EOF
autoreconf -ivf
./configure
make
Thanks,
--
Peter Johansson
svndigest maintainer, http://dev.thep.lu.se/svndigest
yat maintainer, http://dev.thep.lu.se/yat
ilt at 3) which
is later.
If there is no difference between header.h in install 1) and 4) your
suggestion might be a good idea, but to get that behavior you can use
`install.sh -C'.
Cheers,
--
Peter Johansson
svndigest maintainer, http://dev.thep.lu.se/svndigest
yat maintainer, http://dev.thep.lu.se/yat
Hi Karl,
Karl Berry wrote:
I just learned that in some circumstances automake will insert a COPYING
file if it's missing (albeit with a warning), e.g., at make dist? (I
didn't look into the precise details.)
This is a very old feature and according to NEWS it was actually
deprecated in vers
It would be great if Automake could take care of this case, because it
is always a bit annoying to be forced to email co-developers saying:
"you need to run autoreconf".
I use Automake 1.10 and Autoconf 2.61.
Thanks,
Peter
--
Peter Johansson
svndigest maintainer, http://dev.thep.lu.se/svndigest
yat maintainer, http://dev.thep.lu.se/yat
It would be great if Automake could take care of this case, because it
is always a bit annoying to be forced to email co-developers saying:
"you need to run autoreconf".
I use Automake 1.10 and Autoconf 2.61.
Thanks,
Peter
--
Peter Johansson
svndigest maintainer, http://dev.thep.lu.se/svndigest
yat maintainer, http://dev.thep.lu.se/yat
53 matches
Mail list logo
