bug#19311: [FYI] {minor} Expose automake bug#19311

On 17 Dec 2014 17:13, Stefano Lattarini wrote: > AC_PROG_CC called before AC_CONFIG_AUX_DIR can silently force wrong > $ac_aux_dir definition. looks like this was merged to fix this bug but forgot to close the report -mike

bug#42051: Automake Bug

It seems there is nothing to do about this autom4te issue on the automake side, so closing here ... --thanks, karl.

bug#42051: Automake Bug

Although it's hard to tell from the symptoms, my guess is that it's some sort of issue with autom4te calling the wrong version of M4 (or maybe of Perl), or M4 not being installed in the right place in your VM, or something like that. Can you specify which version of RHEL you're using, and give

bug#42051: Automake Bug

Use of uninitialized value $msg in concatenation (.) or string at /usr/bin/autom4te line 1027. Yes, autom4te is part of autoconf, not automake. Can you please mail bug-autoc...@gnu.org? (I'd redirect this bug but my previous attempts at redirection have not worked.) Also, I doubt anyone w

bug#42051: Automake Bug

Hello, I am attempting to build a project using autotools; however, I keep getting this error. My project builds just fine on an iHAwk PC using the same version of the autotools. I am trying to build it in a RHEL virtual machine though, and it won't work. Base on my reading this bug may ac

bug#13928: Closing automake bug#13928 (bad interactions between 'subdir-object' option and automatic dependency tracking)

close 13928 thanks Reference: I've merged the latest patch series: into the 'minor' and 'master' branches, and the testsuite appears to be happy (or at least no more unhappy than before) on

bug#13928: [PATCH 0/4] Fix automake bug#13928

Stefano Lattarini (4): deps: 'subdir-object' option now works when foo_SOURCES contains $(var) tests: fix some bugs in an XFAILing test compile: don't place built object files in $(srcdir), ever ... deps: fix corner-case "make distclean" bug NEWS | 43 +++

bug#18286: [PATCH 1/2] tests: expose automake bug#18286 "distcheck fails to detect missing files"

"make distcheck" detects all missing files, without getting +# confused by the fact that they exists in the "original" source tree +# from which "make distcheck" is run. See automake bug#18286. + +. test-init.sh + +echo AC_OUTPUT >> configure.ac + +cat > Makefile

bug#14898: closing automake bug 14898

tags 14898 wontfix close 14898 stop Bug opened for too long, and the different failures reported here have been (as asked) reported as new, more granular bugs: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14959 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14960 http://debbugs.gnu.org/cgi/bugrepo

bug#19311: [FYI] {minor} Expose automake bug#19311

not, see <http://www.gnu.org/licenses/>. + +# Automake bug#19311: AC_PROG_CC called before AC_CONFIG_AUX_DIR can +# silently force wrong $ac_aux_dir definition. + +am_create_testdir=empty +required=cc +. test-init.sh + +cat > configure.ac < Makefile.am + +mkdir build-aux + +$ACLOCAL +

bug#14560: [PATCH 1/2] tests: expose automake bug#14560

y of the GNU General Public License +# along with this program. If not, see <http://www.gnu.org/licenses/>. + +# Automake bug#14560: if multiple user-specified suffix rules were +# present, Automake could generate useless definitions and rules +# related to C compilation. + +. test-init.sh + +cat > Make

bug#14560: [PATCH 0/2] Fix automake bug#14560

Will push this to 'micro' by tomorrow if there is no objection. On-field testing would be appreciated. Stefano Lattarini (2): tests: expose automake bug#14560 lang, suffix rules: don't require C stuff needlessly NEWS | 11

bug#14441: [PATCH 0/8] Fix automake bug#14441, and related minor refactorings

On 05/28/2013 11:45 AM, Stefano Lattarini wrote: > Reference: > <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14441> > > I plan to push this (to 'micro') in a day or so. > > Stefano Lattarini (8): > tests: expose automake bug#14441 > Automake::Rule:

bug#14441: [PATCH 1/8] tests: expose automake bug#14441

* t/suffix-custom-pr14441.sh: New test, still failing. * t/list-of-tests.mk (handwritten_TESTS, XFAIL_TESTS): Add it. Helped-by: Felix Salfelder Signed-off-by: Stefano Lattarini --- THANKS | 1 + t/list-of-tests.mk | 2 ++ t/suffix-custom-pr14441.sh | 56 ++

bug#14441: [PATCH 0/8] Fix automake bug#14441, and related minor refactorings

Reference: <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14441> I plan to push this (to 'micro') in a day or so. Stefano Lattarini (8): tests: expose automake bug#14441 Automake::Rule: expose suffix rules as a function, not a scalar suffix rules: better distinction between

bug#12554: [PATCH 0/7][PATCH 0/7] Fix automake bug#12554.

tags 12554 + patches close 12554 stop On 04/29/2013 11:00 PM, Stefano Lattarini wrote: > Reference: > > > I will apply this series in a couple pf days, barring objections. > Feedback and testing is welcome > > Stefano Lattarini (7): > tests:

bug#14309: [PATCH 0/7][PATCH 0/7] Fix automake bug#12554.

Reference: I will apply this series in a couple pf days, barring objections. Feedback and testing is welcome Stefano Lattarini (7): tests: expose bug#12554 (false positives for presence of '-k' make option) header-vars: new variable $(am__r

bug#13760: [PATCH 2/2] coverage: expose automake bug#13760

ot;\$MAKE is not GNU make" --dry-run -k # ---------- +# Automake bug#13760: the "n" in "none" used to confound am__make_dryrun +# into thinking the '-n' option had been passed. + +pr='bug#137

bug#11524: ping on automake bug#11524

On 11/26/2012 08:08 PM, Dagobert Michelsen wrote: > Hi Stefano, > >> Am 26.11.2012 um 12:38 schrieb Stefano Lattarini >> : >>> >>> OK, this reeks of spurious failure. >>> >>> ... >>> compilation terminated. >>> configure:2949: $? = 1 >>> configure:2969: checking whether the C compiler wor

bug#11524: ping on automake bug#11524

Hi Stefano, Am 26.11.2012 um 12:44 schrieb Dagobert Michelsen : > Hi Stefano, > Am 26.11.2012 um 12:38 schrieb Stefano Lattarini > : > >> On 11/22/2012 10:42 AM, Stefano Lattarini wrote: >>> On 11/21/2012 10:17 PM, Dagobert Michelsen wrote: I still get quite some failures: http:/

bug#11524: ping on automake bug#11524

Hi Stefano, Am 26.11.2012 um 12:38 schrieb Stefano Lattarini : > On 11/22/2012 10:42 AM, Stefano Lattarini wrote: >> On 11/21/2012 10:17 PM, Dagobert Michelsen wrote: >>> >>> I still get quite some failures: >>> http://buildfarm.opencsw.org/~dam/automake-1.12.5-test-suite.log >> >>> FAIL: t/dep

bug#11524: ping on automake bug#11524

On 11/22/2012 10:42 AM, Stefano Lattarini wrote: > On 11/21/2012 10:17 PM, Dagobert Michelsen wrote: >> >> I still get quite some failures: >> http://buildfarm.opencsw.org/~dam/automake-1.12.5-test-suite.log > >> FAIL: t/depcomp-lt-cpp >> == >> >> depcomp-lt-cpp: running libt

bug#11524: ping on automake bug#11524

s out this failure: > > FAIL: t/amhello-binpkg > is a spurious one, due to a tiny difference in the "tar cvf" output. The patch below should take care of it. Can you confirm it does the trick? Thanks, Stefano 8< 8< 8< 8< 8< 8< --

bug#11524: ping on automake bug#11524

. > >> /bin/bash ./ylwrap `test -f 'lexer.l' || echo './'`lexer.l \ >> lex.yy.c foo-lexer.c -- flex --header-file=mylex.h >> flex: unknown flag '-'. For usage, try >> flex --help >> *** Error code 1 >> make: Fatal error: Comm

bug#11524: ping on automake bug#11524

Hi Stefano, sorry fot the delay, I was away. Am 22.11.2012 um 10:50 schrieb Stefano Lattarini : > On 11/21/2012 10:17 PM, Dagobert Michelsen wrote: >> >> I still get quite some failures: >> http://buildfarm.opencsw.org/~dam/automake-1.12.5-test-suite.log >> > >> FAIL: t/amhello-binpkg >>

bug#11524: bug#12836: bug#11524: ping on automake bug#11524

ho './'`lexer.l \ >>lex.yy.c foo-lexer.c -- flex --header-file=mylex.h >> flex: unknown flag '-'. For usage, try >> flex --help >> *** Error code 1 >> make: Fatal error: Command failed for target `foo-lexer.c' >> > ... doesn&#

bug#11524: ping on automake bug#11524

On 11/21/2012 10:17 PM, Dagobert Michelsen wrote: > > I still get quite some failures: > http://buildfarm.opencsw.org/~dam/automake-1.12.5-test-suite.log > > FAIL: t/amhello-binpkg > == > > [SNIP] > > + make > make all-recursive > Making all in src > source='main.c' object

bug#11524: ping on automake bug#11524

On 11/21/2012 10:17 PM, Dagobert Michelsen wrote: > > I still get quite some failures: > http://buildfarm.opencsw.org/~dam/automake-1.12.5-test-suite.log > FAIL: t/depcomp-lt-cpp > == > > depcomp-lt-cpp: running libtoolize --version > libtoolize (GNU libtool) 2.4.2 > [SNIP]

bug#12836: bug#11524: ping on automake bug#11524

usage, try > flex --help > *** Error code 1 > make: Fatal error: Command failed for target `foo-lexer.c' > ... doesn't support the '--header-file' option. This issue has been reported once already (in automake bug#12836, which I am CC:ing). The patch should take

bug#11524: ping on automake bug#11524

Hi Stefano, Am 21.11.2012 um 11:11 schrieb Stefano Lattarini : > Reference: > > > Any news on this bug? Can it still be reproduced with Automake 1.12.5? > Can it be reproduced with the development version of Automake from the > 'master' branch

bug#11524: ping on automake bug#11524

Reference: On 09/12/2012 09:33 AM, Stefano Lattarini wrote: > On 09/12/2012 09:12 AM, Dagobert Michelsen wrote: >> Hi Stefano, >> > Hi Dagobert, thanks for not giving up on this. > >> Am 11.09.2012 um 17:29 schrieb Dagobert Michelsen : >>> Am 1

bug#11524: ping on automake bug#11524

On 09/12/2012 09:12 AM, Dagobert Michelsen wrote: > Hi Stefano, > Hi Dagobert, thanks for not giving up on this. > Am 11.09.2012 um 17:29 schrieb Dagobert Michelsen : >> Am 11.09.2012 um 11:01 schrieb Stefano Lattarini >> : >>> Resurrecting an oldish bug report: >>>

bug#11524: ping on automake bug#11524

Hi Stefano, Am 11.09.2012 um 17:29 schrieb Dagobert Michelsen : > Am 11.09.2012 um 11:01 schrieb Stefano Lattarini > : >> Resurrecting an oldish bug report: >> >> >> Can you still reproduce the failures reported in bug#11524 with the >> latest

bug#11524: ping on automake bug#11524

Hi Stefano, Am 11.09.2012 um 11:01 schrieb Stefano Lattarini : > Resurrecting an oldish bug report: > > > Hi Dagobert. > > Can you still reproduce the failures reported in bug#11524 with the > latest Automake version (1.12.3)? If not, I will

bug#12372: [FYI 2/2] {maint} coverage: better exposure for automake bug#12372 (tags-related)

Alas, in contrast with what is said in the commit message of previous commit 'v1.12.3-14-g94b7b8e', that bug is still present also in the current maint branch (which will become automake version 1.12.4); it is just that it only triggers when a _SOURCES variable contains only files with custom exten

bug#12372: [FYI 1/2] {maint} coverage: expose automake bug#12372 (tags-related)

along with this program. If not, see <http://www.gnu.org/licenses/>. + +# Test to make sure tags are processed also for files with non-standard +# extensions. See automake bug#12372. + +required='cc etags' +. ./defs || exit 1 + +cat >> configure.ac <<'END' +AC_P

bug#11524: ping on automake bug#11524

Resurrecting an oldish bug report: Hi Dagobert. Can you still reproduce the failures reported in bug#11524 with the latest Automake version (1.12.3)? If not, I will close the bug. Regards, Stefano

bug#9859: automake bug#9859 has been fixed in Automake-NG

JFTR: this bug has been fixed in the Automake-NG fork of Automake (which assumes GNU make is used to execute its generated makefiles); see commits v1.11-1838-gdc04691 "[ng] yacc, lex: fix subdir VPATH builds" and v1.11-1839-ge5b964c "[ng] yacc, lex, compiling: better use of '$<' (simplify and fix b

bug#8881: this is not an automake bug

tags 8881 notabug close 8881 thanks Reference: I've re-read the whole thread, and I've convinced myself that this issue has nothing to do with automake. I'm thus closing this bug report. Feel free to reopen it in case you believe I've missed

bug#9708: close automake bug#9708

tags 9708 wontfix close 9708 thanks I had forgotten to correctly tag and close this bug report. I'm doing that now. Sorry for the delay. Regards, Stefano

bug#10301: Problems in $(LIBTOOL) deifnition (was: Re: automake bug#10301: /bin/sh used to execute libtool)

On 15 December 2011 11:54, Stefano Lattarini wrote: >> >> I'm cross-compiling gettext to mingw32-target in linux system. I have >> to regenerate build system (so it's not the one distributed with >> gettext 0.18.1.1). I end with libtool-script that has /bin/bash as >> shebang. Yet when doing the b

bug#10301: Problems in $(LIBTOOL) deifnition (was: Re: automake bug#10301: /bin/sh used to execute libtool)

[CC:ing bug-libtool] Hi Marko, thanks for the report. On Wednesday 14 December 2011, Marko Lindqvist wrote: > I'm not entirely sure if this is automake or libtool bug, but assuming > automake so reporting here. > > I'm cross-compiling gettext to mingw32-target in linux system. I have > to regener

bug#7374: Automake bug when moving files to different directory

On Thu, 11 Nov 2010 21:38:01 +0100 Ralf Wildenhues wrote: > * Török Edwin wrote on Thu, Nov 11, 2010 at 09:10:56PM CET: > > On Thu, 11 Nov 2010 20:42:05 +0100 Ralf Wildenhues wrote: > > > * Török Edwin wrote on Thu, Nov 11, 2010 at 01:11:44PM CET: > > > > I think that: > > > > - make clean shoul

bug#7374: Automake bug when moving files to different directory

* Török Edwin wrote on Thu, Nov 11, 2010 at 09:10:56PM CET: > On Thu, 11 Nov 2010 20:42:05 +0100 Ralf Wildenhues wrote: > > * Török Edwin wrote on Thu, Nov 11, 2010 at 01:11:44PM CET: > > > I think that: > > > - make clean should remove the dependency files if they're out of > > >date/wrong >

bug#7374: Automake bug when moving files to different directory

t; > How come this happens at all for your buildbots? Do they do > incremental builds only, rather than full rebuilds from scratch? I'd > expect bots to mostly do the latter, unlike developers while hacking. They do incremental builds to save some time, there are parts of the code tha

bug#7374: Automake bug when moving files to different directory

Hi Török, thanks for the bug report. * Török Edwin wrote on Thu, Nov 11, 2010 at 01:11:44PM CET: > Whenever I move a C/C++ file from a directory to another (and update > Makefile.am), a subsequent 'make' fails because it is looking for the > file in the old place (the .Plo dependency file actuall

bug#7374: Automake bug when moving files to different directory

Hi, Whenever I move a C/C++ file from a directory to another (and update Makefile.am), a subsequent 'make' fails because it is looking for the file in the old place (the .Plo dependency file actually). For exampling moving test1/Foo.c to test2/Foo.c results in this error: make: *** No rule to mak

bug#7209: test automake bug

Let's close this test PR.

diagnose duplicate sources (was: found automake bug)

Hello Andreas, * Andreas Otto wrote on Sun, Apr 19, 2009 at 11:02:00AM CEST: > > I wrote the following line into my Makefile.am: > > pymsgque_la_SOURCES = pymsgque.c pymsgque.c pymisc.c > > -> double include the file "pymsgque.c" > > and got the following compile error [...] > -> please ch

found automake bug

Hi, I wrote the following line into my Makefile.am: pymsgque_la_SOURCES = pymsgque.c pymsgque.c pymisc.c -> double include the file "pymsgque.c" and got the following compile error :!make 2>&1| tee /tmp/v152727/13 /bin/sh ../libtool --tag=CC --mode=link ccache gcc -std=gnu99 -I../src

Re: automake bug

Hello, On Thu, Nov 03, 2005 at 01:00:50PM -0600, J J Urich wrote: > gmake[2]: *** [check-TESTS] Error 1 > gmake[2]: Leaving directory `/usr/local/src/automake-1.9.6/tests' I'm not sure I see where is the problem. Could you please follow the instructions in automake-1.9.6/tests/README and send a

automake bug

gmake[2]: *** [check-TESTS] Error 1 gmake[2]: Leaving directory `/usr/local/src/automake-1.9.6/tests' gmake[1]: *** [check-am] Error 2 gmake[1]: Leaving directory `/usr/local/src/automake-1.9.6/tests' gmake: *** [check-recursive] Error 1 [EMAIL PROTECTED] # uname -a HP-UX server B.11.23 U ia64 01