Hi everybody.
I'm not sure if this is the right place to report this, but it seemed
the most appropriate IMHO.
I found a broken symlink in the online html versions of the autoconf
manual, more precisely:
* the link `Compatibility' at the bottom of the page
Hello everybody.
I encountered the following strage behaviour in the latest stable
autoconf (2.65, Debian package version 2.65-2), and it really seems
a bug to me:
$ cat configure.ac EOF
AC_INIT
AC_PROG_CC
AC_PROG_F77
EOF
$ autoconf
$ ./configure CC=gcc F77=gfortran; echo rc=$? # works
At Saturday 06 February 2010, Ralf Wildenhues ralf.wildenh...@gmx.de wrote:
Hello Stefano,
Hello Ralf. Thanks for your quick answer.
* Stefano Lattarini wrote on Sat, Feb 06, 2010 at 04:14:45PM CET:
I encountered the following strage behaviour in the latest stable
autoconf (2.65, Debian
At Friday 04 June 2010, Russ Allbery r...@stanford.edu wrote:
Eric Blake ebl...@redhat.com writes:
Thanks for the report. However, English is one of those silly
languages where the pronoun his can have a neuter sense rather
than masculine, and this is one of those cases. Politically
This is a minimal example exposing a bug that bit me while I was
running the Automake testsuite on a Solaris system. The bug seems
to be located in the macro `AC_FC_LIBRARY_LDFLAGS'.
$ cat configure.ac
AC_INIT([foo], [1.0])
AC_PROG_FC
AC_FC_LIBRARY_LDFLAGS
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
At Thursday 01 July 2010, Eric Blake wrote:
Would you care to prepare a patch?
Sure. Probably won't be very soonish, though.
Regards,
Stefano
On Wednesday 15 September 2010, Eric Blake wrote:
[dropping all but bug-autoconf]
On 09/15/2010 09:15 AM, Eric Blake wrote:
[adding bug-autoconf]
On 09/15/2010 09:13 AM, Stefano Lattarini wrote:
Ouch! On my Debian box, I had to build my own autoconf 2.67 from
sources to use
On Thursday 16 September 2010, Eric Blake wrote:
On 07/01/2010 07:00 AM, Stefano Lattarini wrote:
This is a minimal example exposing a bug that bit me while I was
running the Automake testsuite on a Solaris system. The bug
seems to be located in the macro `AC_FC_LIBRARY_LDFLAGS
On Thursday 16 September 2010, Eric Blake wrote:
On 09/15/2010 09:48 AM, Stefano Lattarini wrote:
http://lists.freedesktop.org/archives/pkg-config/2010-Augus
t/0 00631.html
(which has since been fixed in the pkg-config git repo, BTW).
There should be a reference also
Hi Eric. Thanks for looking into this; unfortunately, your
patch doesn't work :-(
On Thursday 16 September 2010, Eric Blake wrote:
On 09/15/2010 04:38 PM, Stefano Lattarini wrote:
On Thursday 16 September 2010, Eric Blake wrote:
On 07/01/2010 07:00 AM, Stefano Lattarini wrote
On Thursday 16 September 2010, Eric Blake wrote:
Not just yet; let's try this patch first (and I feel better about
it not being as global of a change):
--- i/lib/autoconf/fortran.m4
+++ w/lib/autoconf/fortran.m4
@@ -505,7 +505,8 @@ _AS_ECHO_LOG([$[*]])
# gfortran 4.3 outputs lines
FCLIBS from Fortran compiler
| * lib/autoconf/fortran.m4 (_AC_PROG_FC_V_OUTPUT): Also skip
| 'Configured by:' lines from gfortran.
| * NEWS: Mention it.
| Reported by Stefano Lattarini.
|
| 2010-09-16 Ralf Wildenhues ralf.wildenh...@gmx.de
|
## - ##
## Platform
parallel autotest and signal handling
## -- ##
## ChangeLog. ##
## -- ##
| 2010-09-16 Eric Blake ebl...@redhat.com
|
| m4sh: fix today's AS_BOX regression
| * lib/m4sugar/m4sh.m4 (_AS_BOX_LITERAL): Fix underquotation.
| Reported by Stefano Lattarini.
|
| fortran: avoid
On Sunday 15 May 2011, Stefano Lattarini wrote:
Hello autoconfers.
It seems that AC_PROG_LEX does not diagnose a failure to find the lex
library required to link lex-generated programs; on the contrary, when
all the link attempts (i.e., with `-ll' and `-lfl') fail, configure
uncorrectly
Hi Russ, sorry for the dealy.
On Thursday 19 May 2011, Russ Allbery wrote:
Stefano Lattarini stefano.lattar...@gmail.com writes:
It seems that AC_PROG_LEX does not diagnose a failure to find the lex
library required to link lex-generated programs; on the contrary, when
all the link
Hi Jim. Probably you're totally going to hate me today, but ...
On Monday 13 June 2011, Jim Meyering wrote:
From d987cf87de5e7e597e295914c536bd332c24cc63 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Mon, 13 Jun 2011 18:54:53 +0200
Subject: [PATCH] init.sh: redirect
On Monday 13 June 2011, Stefano Lattarini wrote:
Hi Jim. Probably you're totally going to hate me today, but ...
On Monday 13 June 2011, Jim Meyering wrote:
From d987cf87de5e7e597e295914c536bd332c24cc63 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Mon, 13 Jun
On Monday 13 June 2011, Eric Blake wrote:
On 06/13/2011 02:32 PM, Stefano Lattarini wrote:
+++ b/tests/init.sh
@@ -317,6 +317,11 @@ path_prepend_ ()
setup_ ()
{
+ # If we're redirecting a file descriptor larger than 2, say via
automake's
+ # TESTS_ENVIRONMENT, that redirected
On Monday 13 June 2011, Stefano Lattarini wrote:
On Monday 13 June 2011, Stefano Lattarini wrote:
Hi Jim. Probably you're totally going to hate me today, but ...
On Monday 13 June 2011, Jim Meyering wrote:
From d987cf87de5e7e597e295914c536bd332c24cc63 Mon Sep 17 00:00:00 2001
On Monday 13 June 2011, Eric Blake wrote:
Not possible to portably sniff out closed fds; quoting the autoconf manual:
Don't rely on duplicating a closed file descriptor to cause an
error. With Solaris @command{/bin/sh}, when the redirection fails, the
output goes to the original file
On Tuesday 14 June 2011, Eric Blake wrote:
On 06/13/2011 03:39 PM, Stefano Lattarini wrote:
[3] The $(SHELL), which here we assume is ksh with close-on-exec, does a
fork+exec to execute the test script; thus, when that script begins
its execution, it has the fd 9 closed (d'oh
/13/2011 04:24 PM, Stefano Lattarini wrote:
On Monday 13 June 2011, Eric Blake wrote:
Not possible to portably sniff out closed fds; quoting the autoconf manual:
Don't rely on duplicating a closed file descriptor to cause an
error. With Solaris @command{/bin/sh}, when the redirection
/archive/html/bug-autoconf/2011-06/msg00018.html
http://lists.gnu.org/archive/html/bug-coreutils/2011-06/msg00082.html
On Tuesday 14 June 2011, Eric Blake wrote:
On 06/13/2011 04:29 PM, Stefano Lattarini wrote:
If this work, then using a bare `2' *at the end of TESTS_ENVIRONMENT* and
You meant
/gmane.comp.gnu.coreutils.bugs/22488
for lots of discussion. Stefano Lattarini suggested the solution
of putting 92 after the command. Reported by Bruno Haible.
---
tests/check.mk |3 +--
tests/init.sh |4 ++--
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/tests/check.mk b
Hello Křištof.
On Wednesday 27 July 2011, Křištof Želechovski wrote:
{ autoreconf -V; }
autoreconf (GNU Autoconf) 2.68
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html,
On Wednesday 27 July 2011, Stefano Lattarini wrote:
Hello Křištof.
On Wednesday 27 July 2011, Křištof Želechovski wrote:
{ autoreconf -V; }
autoreconf (GNU Autoconf) 2.68
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
http
[CC:ing bug-autoconf, about a FreeBSD make bug]
On Friday 12 August 2011, Stefano Lattarini wrote:
OK, the attached hacky patch seems to fix the bug. I have no idea why
exactly it is so yet, so we might want to wait to apply the patch until
we have fully understood the reasons of the original
On Friday 12 August 2011, Stefano Lattarini wrote:
[CC:ing bug-autoconf, about a FreeBSD make bug]
[SNIP]
This issue should IMHO be probably reported to the FreeBSD developers
Done, see freebsd pr `bin/159730':
http://www.freebsd.org/cgi/query-pr.cgi?pr=159730
Regards,
Stefano
Hello autoconfers.
I've found this problem some times ago when extending the automake
testsuite. Sorry for only reporting it now.
$ cat foo.c
#include stdio.h
#include stdlib.h
#include sys/wait.h
int main(void)
{
int wstatus = system(kill -15 $$);
printf (RETURN: 0x%x\n,
On Solaris 10, I'm observing this:
$ cmd=perl -e 'kill 2, \$\$; exit 0'; echo alive
$ bash -c $cmd; echo $?
alive
0
$ dash -c $cmd; echo $?
alive
0
$ /bin/sh -c $cmd; echo $?
alive
0
$ /bin/ksh -c $cmd; echo $?
130
$ /usr/xpg4/bin/sh -c $cmd; echo $?
130
I think this horrible
On Monday 12 September 2011, Paul Eggert wrote:
On 09/12/11 09:19, Stefano Lattarini wrote:
This example might show the problem more clearly:
Yes, thanks, that does clarify matters, and my guesses seem
incorrect. It does seem that ksh's behavior (in your last
example, anyway) violates
On Monday 12 September 2011, Stefano Lattarini wrote:
Now some updates: the default Korn Shell on Debian GNU/Linux (package
`ksh', version `93u-1') seems to exhibit the same issue:
$ ksh -c perl -e 'kill 2, \$\$'; :; echo $?
130
And if I'm not reading the strace output wrong
On Monday 12 September 2011, Paul Eggert wrote:
On 09/12/11 11:17, Stefano Lattarini wrote:
this is due to the fact
that the Debian korn shell is apparently killing itself (yikes!) with the
same signal that killed the child process:
That's actually a fairly standard trick, one that I've
Hello autoconfers.
When doing a make check from the autoconf master branch
(v2.68-95-ge0cb97a), the mentioned test fails, with this log:
$ cat tests/testsuite.dir/048/testsuite.log
# -*- compilation -*-
48. m4sugar.at:527: testing m4_require: nested ...
Reference:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8788
[Adding bug-autoconf in CC]
On Thursday 02 June 2011, Stefano Lattarini wrote:
Hello automakers.
While teststing the `testsuite-work' branch on NetBSD 5, I've encountered
a weird failure in the test `parallel-tests3.test', which
Feeding the on-line autoconf manual:
http://www.gnu.org/software/autoconf/manual/autoconf.html
to the W3C linkchecker:
http://validator.w3.org/checklink
I've found the following *broken links*:
http://www.opengroup.org/austin/mailarchives/ag-review/msg03507.html
Reference:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10766
[CC:ing the bug-autoconf list]
On 02/08/2012 10:04 PM, Peter Rosin wrote:
Hi!
The testsuite on master tries to use lesser compilers, but on Cygwin
this causes some failures due to the fact that /usr/bin/cc{.exe} is
also
On 02/16/2012 10:08 PM, Eric Blake wrote:
[dropping coreutils, as we are now moving on to what autoconf should
document]
On 02/16/2012 11:58 AM, Eric Blake wrote:
As would I. My tests were pretty extensive, hitting some rather old
machines:
FreeBSD 6.4
AIX 5.1
HP-UX 10.20
IRIX 6.5
: 3115f7a37445fd404b0de300894a790d1ce0cb68.1329570443.git.stefano.lattar...@gmail.com
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Sat, 18 Feb 2012 13:59:26 +0100
Subject: [PATCH] parallel-tests: fix another BSD parallel make issue
When BSD make is run in parallel mode, it apparently strips any
leading directory
On 02/18/2012 02:09 PM, Stefano Lattarini wrote:
[CC:ing bug-autoconf for Yet Another BSD make Bug, in case someone
cares to documenting it ...]
When BSD make is run in parallel mode, it apparently strips any leading
directory component from the automatic variable '$*' (of course, against
On 02/18/2012 11:12 PM, Stefano Lattarini wrote:
On 02/18/2012 02:09 PM, Stefano Lattarini wrote:
[CC:ing bug-autoconf for Yet Another BSD make Bug, in case someone
cares to documenting it ...]
When BSD make is run in parallel mode, it apparently strips any leading
directory component from
[CC:ing bug-autoconf]
Reference:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10859
On 02/21/2012 09:44 PM, Panther Martin wrote:
On Feb 20, 2012, Stefano Lattarini stefano.lattar...@gmail.com wrote:
Hmm... this doesn't ring a bell right away, even after I've looked into the
attached
On 03/02/2012 08:53 AM, Paul Eggert wrote:
The symptoms are:
$ cd tests; make check TESTSUITEFLAGS=75
make check-local
/bin/bash ./testsuite 75
## -- ##
## GNU Autoconf 2.68b test suite. ##
## -- ##
75: Configure re-execs self
Hi Paul, Eric.
Paul Eggert wrote:
Solaris 8 ships with Perl 5.005_03. This satisfies Autoconf 'configure',
which requires only 5.005_03 or better. But
lib/Autom4te/Getopt.pm and lib/Autom4te/General.pm
require 5.006_002.
As I can test with at most with perl 5.6.2 (and no older versions),
Hi Eric.
On 03/02/2012 04:08 PM, Eric Blake wrote:
On 03/02/2012 07:15 AM, Stefano Lattarini wrote:
Also, note that the workaround removed in c3797b86ccbd9 was severely
broken to begin with (that is explained in the commit message);
re-introducing it only to make autoconf buildable out
: Stefano Lattarini stefano.lattar...@gmail.com
Date: Sat, 3 Mar 2012 10:44:25 +0100
Subject: [PATCH] configure: don't infloop when re-executing with
$CONFIG_SHELL
It turns out our guard against infinite recursion wasn't good
enough when shells without $LINENO support were involved, since
the creation
On 03/03/2012 02:42 PM, Eric Blake wrote:
On 03/03/2012 02:46 AM, Stefano Lattarini wrote:
Tim Rice wrote:
On my UnixWare 7.1.4 box, the tests get stuck on
75: Configure re-execs self with CONFIG_SHELL
It seems to me that the problem happens only with shells that do not
expand $LINENO
On 03/04/2012 04:28 PM, Stefano Lattarini wrote:
On a Solaris 10 system:
ERROR: 493 tests were run,
7 failed (4 expected failures).
10 tests were skipped.
Details are attached.
The failure of test 75 was due to a testsuite weakness; I've just committed a
fix for that to master.
Regards
On 03/04/2012 04:34 PM, Stefano Lattarini wrote:
On 03/04/2012 04:28 PM, Stefano Lattarini wrote:
On a Solaris 10 system:
ERROR: 493 tests were run,
7 failed (4 expected failures).
10 tests were skipped.
Details are attached.
The failure of test 75 was due to a testsuite weakness; I've
Hi Paul.
On 03/04/2012 06:54 PM, Paul Eggert wrote:
On 03/04/2012 08:16 AM, Stefano Lattarini wrote:
What's going on there?
That is a bug in older ksh implementations.
I've pushed the following doc patch to describe it.
I don't fully understand your test case, but renaming
script
When I go to:
http://www.gnu.org/software/autoconf/manual/autoconf.html
I see:
This manual (21 September 2010) is for GNU Autoconf (version 2.68), ...
So the on-line manual hasn't been updated to Autoconf 2.69. This is a pity,
especially because the new version of the manual documents a
[Adding bug-autoconf]
On 06/27/2012 12:40 AM, Jonathan Nieder wrote:
Hi,
Quick first impressions:
Anders Kaseorg wrote:
Sidestep this problem by opening the backflow FIFO once for
read+write.
Is that portable?
According to the Autoconf manual, no:
Some shells, like ash, don't
On 06/28/2012 12:01 AM, Eric Blake wrote:
On 06/26/2012 04:56 PM, Stefano Lattarini wrote:
AM_MISSING_PROG has been around for a while (git log says it was
introduced in 1997, although the current two-argument version appears to
date back to commit 9ae48df in Nov 1999), and seems like
[Adding bug-autoconf]
Reference:
http://lists.gnu.org/archive/html/automake-patches/2012-07/msg00011.html
On 07/04/2012 11:23 AM, Stefano Lattarini wrote:
On 07/04/2012 11:03 AM, Ralf Corsepius wrote:
Please revert this change.
No. Have you read my plan above? If the use case of multiple
AC_CONFIG_MACRO_DIR): Adjust.
(autoreconf Invocation): Warn about the possible future removal of
$(ACLOCAL_AMFLAGS) support from Automake.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
doc/autoconf.texi |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/doc
On 07/04/2012 01:03 PM, Eric Blake wrote:
On 07/04/2012 04:55 AM, Stefano Lattarini wrote:
This will allow projects to use several m4 macro local dirs. This is
especially important for projects that are used as nested subpackages
of larger projects.
See also:
http://lists.gnu.org/archive
On 07/04/2012 01:28 PM, Eric Blake wrote:
On 07/04/2012 05:03 AM, Eric Blake wrote:
Would it also make sense to allow multiple calls to AC_CONFIG_MACRO_DIR
to stack, as in:
AC_CONFIG_MACRO_DIR([dir1])
AC_CONFIG_MACRO_DIR([dir2])
And should we mention that the first directory listed has
On 07/04/2012 01:28 PM, Eric Blake wrote:
On 07/04/2012 05:03 AM, Eric Blake wrote:
Would it also make sense to allow multiple calls to AC_CONFIG_MACRO_DIR
to stack, as in:
AC_CONFIG_MACRO_DIR([dir1])
AC_CONFIG_MACRO_DIR([dir2])
And should we mention that the first directory listed has
Here are the errors that I'm getting:
autoconf.texi:8018: Misplaced }
autoconf.texi:8019: Must be after `@defmac' to use `@defmacx'
autoconf.texi:8020: Misplaced }
autoconf.texi:8207: Must be after `@defmac' to use `@defmacx'
autoconf.texi:8272: Misplaced }
autoconf.texi:8291: Misplaced }
On 07/18/2012 09:46 PM, Eric Blake wrote:
On 07/18/2012 01:21 PM, Patrice Dumas wrote:
On Tue, Jul 17, 2012 at 10:46:58AM -0600, Eric Blake wrote:
tool and therefore which semantics will be encountered). My preference
would be for preserving the existing semantics, so that the autoconf
On 08/06/2012 02:56 PM, Eric Blake wrote:
On 08/04/2012 12:15 PM, Stefano Lattarini wrote:
On current OpenIndiana (based on what once was OpenSolaris 11), the shell
/bin/sh (which, differently from what happens on Solaris, is a true POSIX
shell, thus worthy of consideration) somehow manages
## - ##
## Test results. ##
## - ##
ERROR: 1 test was run,
1 failed unexpectedly.
## ##
## Summary of the failures. ##
## ##
Failed tests:
GNU Autoconf 2.69.23-388d test suite test groups:
NUM: FILE-NAME:LINE
On 09/21/2012 11:20 PM, Eric Blake wrote:
On 09/21/2012 01:34 PM, Stefano Lattarini wrote:
On 09/21/2012 05:50 PM, Eric Blake wrote:
./tools.at:1200: test `find configure -newer newer` = ||
{ diff old-requests autom4te.cache/requests; exit 1; }
Eww - we should really sort
The testsuite.log file is inlined below.
-*-*-*-
## - ##
## GNU Autoconf 2.69.38-b038 test suite. ##
## - ##
testsuite: command line was:
$ ./testsuite -k AC_PROG_CC_.*
## - ##
## Platform. ##
## - ##
Here are the details of the failure:
# -*- compilation -*-
349. go.at:30: testing Go ...
./go.at:30: autoconf --force -W obsolete
./go.at:30: /bin/sh -n configure
stderr:
./go.at:30: autoheader
./go.at:30: ./configure $configure_options -C
--- /dev/null 2012-10-27
Some examples:
$ echo 'AC_INIT([sinclude], [1.0])' | autoconf -o/dev/null -
stdin:1: warning: file `' included several times
$ echo 'AC_INIT([dnl], [1.0])' | autoconf -o/dev/null -
/usr/bin/m4:stdin:1: Warning: excess arguments to builtin `m4_define' ignored
autom4te: /usr/bin/m4
On 11/24/2012 10:50 AM, Eli Zaretskii wrote:
(I'm not subscribed to the list, so please CC me on any responses.)
For the context, see
https://lists.gnu.org/archive/html/emacs-devel/2012-11/msg00441.html
I never before had to do anything serious in Autoconf, so please take
the below
Hi Eric.
On 01/01/2013 12:17 AM, Eric Blake wrote:
On 12/29/2012 04:10 AM, Stefano Lattarini wrote:
## -- ##
## GNU Autoconf 2.69.59-adc84 test suite. ##
## -- ##
Thanks for the report.
NUM: FILE-NAME:LINE
On 01/02/2013 05:18 PM, Eric Blake wrote:
On 01/02/2013 09:03 AM, Stefano Lattarini wrote:
Here it is. OK to push?
* lib/autoconf/go.m4 (_AC_LANG_IO_PROGRAM(Go), AC_LANG_INT_SAVE): Here,
correctly using 'os.OpenFile()' http://golang.org/pkg/os/#OpenFile
s/using/use/
Done.
rather
Hi Markus, thanks for the report.
On 01/02/2013 06:25 PM, Markus Rothe wrote:
I am trying to use autotools to compile go sources. Adding AC_PROG_GO to
configure.ac I am running into the followring error when running
./configure:
checking whether we are cross compiling... configure:
[+cc Automake-NG]
Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13349#31
On 01/03/2013 10:34 PM, Eric Blake wrote:
On 01/03/2013 02:14 PM, Stefano Lattarini wrote:
So what's the verdict - do we (want to) support the user overriding
MAKE, and therefore document that in INSTALL
On 01/03/2013 10:54 PM, Eric Blake wrote:
Based on a suggestion from Bob Friesenhahn:
https://lists.gnu.org/archive/html/bug-automake/2013-01/msg00017.html
* doc/install.texi (Defining Variables): Mention that MAKE
can be overridden, and the caveats that come with setting it.
---
How
On 01/03/2013 11:53 PM, Nick Bowler wrote:
On 2013-01-03 23:05 +0100, Stefano Lattarini wrote:
TARGETS = all check clean distclean dist distcheck install uninstall
.PHONY: $(TARGETS)
$(TARGETS): ; @gmake $(AM_MAKEFLAGS) $@
Unfortunately, this kind of wrapper doesn't work particularly
On 01/04/2013 12:31 AM, Eric Blake wrote:
On 01/03/2013 03:05 PM, Stefano Lattarini wrote:
Yeah, probably AM_INIT_AUTOMAKE should enhance the configure help message
to report the quirky role of $MAKE (patches welcome).
I'll think about an automake patch to make it precious (at this point
On 01/03/2013 11:22 PM, Eric Blake wrote:
On 01/03/2013 03:10 PM, Stefano Lattarini wrote:
On 01/03/2013 10:54 PM, Eric Blake wrote:
Based on a suggestion from Bob Friesenhahn:
https://lists.gnu.org/archive/html/bug-automake/2013-01/msg00017.html
* doc/install.texi (Defining Variables
[Dropping Automake-NG]
On 01/04/2013 01:12 AM, Eric Blake wrote:
On 01/03/2013 04:54 PM, Stefano Lattarini wrote:
Then again, it is autoconf that defines AC_PROG_MAKE_SET which in turn
provides @SET_MAKE@ for substitution in Makefiles;
Right, I had forgotten about that. I somehow just took
[+cc bug-autoconf]
Reference:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#127
On 01/13/2013 10:06 PM, Nick Bowler wrote:
On 2013-01-13, Stefano Lattarini stefano.lattar...@gmail.com wrote:
On 01/13/2013 09:01 PM, Nick Bowler wrote:
+dnl Automatically invoke AM_PROG_CC_C_O as necessary
Hi Paul.
On 01/14/2013 08:45 PM, Paul Eggert wrote:
On 01/14/13 02:24, Stefano Lattarini wrote:
Autoconfers, WDYT?
I think I'm lost. http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378
is a long thread.
Yeah, sorry for not giving a more clear summary.
Here are the main grips I (and I
On 01/15/2013 04:16 AM, Paul Eggert wrote:
On 01/14/2013 11:56 AM, Stefano Lattarini wrote:
1. It checks that *both* 'cc' and '$CC' (which might easily be 'gcc'
or 'clang') supports -c -o together. Why? If the user has a
broken base vendor compiler, but has installed a better one
79 matches
Mail list logo