Re: Checking for memcpy

Mark Nudelman <[EMAIL PROTECTED]> writes: > Is this a bug in autoconf, Yes, but that particular problem is low priority these days, as all C platforms of any practical interest now have memcpy. I'd remove the test for memcpy and assume that memcpy and work.

Re: AC_CHECK_SIZEOF

n't see how to do it for C++, but perhaps a C++ wizard can figure that out later. I installed this: 2007-04-11 Paul Eggert <[EMAIL PROTECTED]> * doc/autoconf.texi (Generic Types): Document the restrictions on types imposed by AC_CHECK_TYPE, AC_CHECK_TYPES. (G

Re: portability note about 'printf'

Thanks, I installed this into the Autoconf manual: 2007-04-26 Paul Eggert <[EMAIL PROTECTED]> * doc/autoconf.texi (Limitations of Builtins): Warn about Solaris /bin/printf '%01x' 123. Problem reported by Arto C. Nirkko via Bruno Haible. Index: d

Re: requirement for newr packages

"robert hawkin" <[EMAIL PROTECTED]> writes: > running the ./configure script does not seem to take into account > whether a package can be compiled, simply the version of the package > the author of the application is using. why cant it use 'locate' > instead of pkg-config to find the headers, and

Re: portability note about 'printf'

#x27;s the latter that is the case. I installed this: 2007-04-29 Paul Eggert <[EMAIL PROTECTED]> * doc/autoconf.texi (Limitations of Builtins): Correct the warning about Solaris /bin/printf '%01x' 123. Problem reported by Bruno Haible. --- doc/

Re: test results

That one's a bit odd. Maybe an installation issue? What does the following output? cd tests truss -f -o trace.out ./testsuite 23 grep 'share/aclocal/*"' trace.out

Re: `autoconf -' does not work twice

Ralf Wildenhues <[EMAIL PROTECTED]> writes: > echo AC_INIT | autoconf - >/dev/null; autoconf - > > does not wait for input from stdin as it should. Rather, it reuses the > output from cache. I think this is a bug, stdin should not be cached. Sounds right to me (since I don't think anything shou

Re: AC_C_RESTRICT and AC_PROG_CC_STDC

Does this need to be reworked, to be consistent with 'restrict'? Or are 'inline' and 'restrict' sufficiently different that we should just leave 'inline' alone? I don't use C++ much so I'm asking you C++ experts. 2007-05-14 Paul Eggert

Re: AC_SUBST() confuses config.status creation

Noah Misch <[EMAIL PROTECTED]> writes: > 2007-06-07 Noah Misch <[EMAIL PROTECTED]> > > * lib/autoconf/general.m4 (AC_SUBST): Raise a fatal error if VARIABLE is > not a valid shell variable name. > * tests/mktests.sh (ac_exclude_list): Add AC_ARG_VAR. > * tests/torture.at

Re: configure: error: no acceptable C compiler found in $PATH (+possible solution)

Thanks for the bug report. I audited Autoconf looking for PATH glitches and installed this patch: 2007-06-13 Paul Eggert <[EMAIL PROTECTED]> * lib/m4sugar/m4sh.m4 (_AS_PATH_SEPARATOR_PREPARE): Set FPATH too. Problem reported by Fred Kreek in <http://list

Re: configure: error: no acceptable C compiler found in $PATH (+possible solution)

Ralf Wildenhues <[EMAIL PROTECTED]> writes: >> [EMAIL PROTECTED] PATH >> -Absolute names of files, including programs. > > What was this change for? AC_PATH_PROG and the like still exist, no? They exist but they don't follow that naming convention. AC_PATH_PROG has that name because it looks in

Re: autoconf-2.61's make fails with make -j2 and up

Chris Pickett <[EMAIL PROTECTED]> writes: > autoconf-2.61's make doesn't like make -j2 That's correct. The autoconf-2.61/BUGS says "Parallel builds via `make -jN' do not work." It'd be nice if someone could fix this, but it won't be trivial.

Re: [GNU Autoconf-2.59] : testsuite: 10

Ibrahim Hassan <[EMAIL PROTECTED]> writes: > ## GNU Autoconf 2.59 test suite. ## 2.59 is pretty old. Please try again with 2.61. > -AC_CONFIG_FILES([Makefile]) > -AC_CONFIG_COMMANDS([default],[[echo $fubar]],[[fubar=$fubar]]) > +AC_CONFIG_FILES([Makefile]) > +AC_CONFIG_COMMANDS([default],[[echo

Re: CVS Automake fails to make check with CVS Autoconf

How about this (untested) patch to Automake? 2007-06-22 Paul Eggert <[EMAIL PROTECTED]> * tests/subst.test: Port to CVS autoconf. Problem reported by Benoit Sigoure in: http://lists.gnu.org/archive/html/automake-patches/2007-06/msg3.html --- automake

Re: [Leo Moisio] Bug#432941: autoconf: autoreconf can't handle multi-line assignment to ACLOCAL_AMFLAGS

Thanks for reporting the problem. I installed this doc fix for now. * doc/autoconf.texi (autoreconf Invocation): Document ACLOCAL_AMFLAGS limitation reported by Leo Moisio in . Index: doc/autoconf.texi ==

Re: [GNU Autoconf 2.61] testsuite: 142 143 144 145 146 147 148 149 failed

Not to worry, it just meant you didn't have a Fortran compiler.

Re: Please normalize command line paths

is more reliable in the presence of weird characters, such as backslashes. I installed this: 2007-10-05 Paul Eggert <[EMAIL PROTECTED]> * lib/autoconf/general.m4 (_AC_INIT_PARSE_ARGS): Handle "///" correctly. diff --git a/lib/autoconf/general.m4 b/lib/autoconf/general.m4 i

Re: Please normalize command line paths

Eric Blake <[EMAIL PROTECTED]> writes: > should we be using $as_expr, with a sed fallback, as in > AS_BASENAME? Earlier parts of our code don't, so I assume it's OK here too.

Re: new AC_USE_SYSTEM_EXTENSIONS breaks Interix?

Jerker Bäck <[EMAIL PROTECTED]> writes: > Besides, there is no bootstrap script in the bison 2.3 package. "bootstrap" is not intended to be used from a tarball. It's intended only for use in bleeding-edge versions that you check out directly from CVS.

Re: stdbool.h test v. Compaq C on Tru64

In a followup to , Ralf Wildenhues <[EMAIL PROTECTED]> writes: > It would be more interesting to see why gnulib's stdbool.h can't cope. I agree. This is a longstanding problem with DEC/Compaq/HP C. It's case 3411658RE in thei

Re: AC_C_RESTRICT and C/C++

Bruno Haible <[EMAIL PROTECTED]> writes: > /* Define to equivalent of C99 restrict keyword, or to nothing if this > is not supported. Do not define if restrict is supported directly. */ > #ifdef __cplusplus > #define restrict > #else > #define restrict _Restrict > #endif That s

Re: AC_C_RESTRICT and C/C++

x 6827771..0044b63 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2007-10-22 Paul Eggert <[EMAIL PROTECTED]> + and Eric Blake <[EMAIL PROTECTED]> + + * lib/autoconf/c.m4 (AC_C_RESTRICT): Work around Sun C++ compatibility + problem reported by Bruno Ha

Re: stdbool.h test v. Compaq C on Tru64

t; mentioned above. Can you please verify that it fixes your problem? Thanks. 2007-10-22 Paul Eggert <[EMAIL PROTECTED]> Fix Tru64 problem with stdbool.h. * lib/stdbool.in.h (false, true): [! (defined __cplusplus || defined __BEOS__) && !defined __GNUC__]:

Re: stdbool.h test v. Compaq C on Tru64

[EMAIL PROTECTED] (Steven M. Schweda) writes: >Now, having failed that (deluxe, rigorous) test, we can advance to > the (newly revised) gnulib stdbool.h, which does _so_ much better: gnulib stdbool.h is not intended as a complete replacement for stdbool.h; it is intended only to be a replacem

Re: AC_PATH_PROG requires target be executable

Stepan Kasal <[EMAIL PROTECTED]> writes: > Should AC_PATH_FILE be added to Autoconf? I'm fine either way. It is tempting to remove the executable-bit test entirely, though.

Re: I think I might have found a bug.

Chris <[EMAIL PROTECTED]> writes: > conftest[6684]: segfault at 00603000 rip 2b5fdba0c02b rsp > 7fffcf52b3e8 error 6 > It is often followed by this error: > init: Trying to re-exec init Cool! One of the autoconf-generated runtime tests is crashing your operating system. Your fir

Re: bug in AC_F77_WRAPPERS macros using ftn cray compiler

"Carlo Cavazzoni" <[EMAIL PROTECTED]> writes: > I've found a bug in autoconf 2.59 configuring our code You might try upgrading to Autoconf 2.61; it has improved support for Cray Fortran.

Re: AC_PROG_LEX broken on IRIX with MIPSpro Compilers

"Peter O'Gorman" <[EMAIL PROTECTED]> writes: > -e { yyless (input () != 0); } > +e { yyless ((input () != 0)); } Why is this patch necessary? yyless is supposed to take an int parameter, and another set of parentheses shouldn't affect the parameter's type or value.

Re: AC_PROG_LEX broken on IRIX with MIPSpro Compilers

"Peter O'Gorman" <[EMAIL PROTECTED]> writes: > After macro expansion that line turns into: > { do { *yy_cp = yy_hold_char; yy_c_buf_p = yy_cp = yy_bp + input () != > 0 - 0; yytext = yy_bp; yyleng = (int) (yy_cp - yy_bp); yy_hold_char = > *yy_cp; *yy_cp = '\0'; yy_c_buf_p = yy_cp;; } while ( 0 );

Re: AC_PROG_LEX broken on IRIX with MIPSpro Compilers

"Peter O'Gorman" <[EMAIL PROTECTED]> writes: > I see no reason why autoconf should not work with flex-2.5.4 though. I suppose it depends on what one means by "work". My own suggestion would be for Autoconf to reject a "lex" implementation that does not implement yyless correctly, as apparently w

Re: Interix cc compiler suddenly fails tests in new 64bit SUA 6.1 RC1

It looks like your compiler is generating a .o file even when it is invoked with the -E option. Perhaps you can track it down by debugging the "configure" script. Try running this: cd tests ./testsuite -v -d 145 and then look at what's in the tests/testsuite.dir/145 directory.

Re: Handling of #undef FOO

Ismail Dönmez <[EMAIL PROTECTED]> writes: > but it should be defined like this, > > #ifndef FOO > #define FOO > #endif Why should it be defined like that? Typically, config.h is supposed to define FOO; if something else is defining FOO first, that's a problem with the "something else", not with

Re: portable use of 'dd'

[EMAIL PROTECTED] (Karl Berry) writes: > I've never thought of that list in Utilities in Makefiles as being all > "utilities whose existence can be assumed everywhere", but rather > "utilities which need to exist to bootstrap a system". In practice I think it means "utilities whose existence are

Re: Portability problems in autoconf manual

It seems that 'trap 1 2 13 15' (without any command) reset the traps in a reasonably portable way, I'm afraid not. For example, on Ubuntu 9.04: $ dash !-penguin $ trap 1 2 !-penguin $ kill -2 $$ dash: 1: not found It's hard to argue that this is a bug, since POSIX requires this behavior. Be

Re: AC_CHECK_SIZEOF([int *]) is error in autoconf-2.66

On 07/03/10 03:18, Nishio Futoshi wrote: > I did something wrong, maybe. No, you didn't. This is a serious bug in Autoconf 2.66, which I hope will be fixed soon. Thanks for reporting it.

Re: how to detect int64?

On 07/18/10 19:01, Jay K wrote: > So, question is, what is wrong with the following seems-simple algorithms: > > > 1) Find the types that exist, char, short, int, long, long long, > their sizes, #include , multiply by CHAR_BIT? > Or probably assume all but long long exist. > Or error out i

Re: how to detect int64?

On 07/19/10 17:24, Jay K wrote: > Wow. > So..it sounds to me like..these systems would have a 31 bit unsigned int > and a 63 bit unsigned long? I believe the Unisys machine has a 36-bit signed int and a 35-bit unsigned int, with longs being about twice as long. (I haven't verified this.) > And t

Re: testsuite failure - 193 parallel execution

On 07/20/10 14:11, Eric Blake wrote: > Hmm, maybe we should do more validation in the parent - not just read > from the fifo, but validate that we actually read a token. That way, we > can ignore EOF (on the grounds that it may be a temporary condition, and > that more children remain to be run)

Re: testsuite failure - 193 parallel execution

On 07/20/10 14:15, Eric Blake wrote: > But for that to work, the token has to be more than a newline (since > read strips newlines). Sorry, I don't follow. If read exits with status 0, it got a newline. If it exits with nonzero status, it did not get a newline. So there's an unambiguous way of

Re: testsuite failure - 193 parallel execution

On 07/20/10 14:47, Eric Blake wrote a bunch of good questions, ending with: > And how does signal handling fit in with interrupting a child test? OK, you're right, a plain pipe is not going to work. How about this much-smaller fix instead? It builds on your idea to make sure that the 'read at_t

Re: testsuite failure - 193 parallel execution

On 07/20/10 14:55, Eric Blake wrote: > the '|| break' that you are deleting is there in case > something kills off the child and it never gets around to writing a > token, at which point we've now put the parent into an inf-loop OK, though if the child is killed off arbitrarily then we're helpless

Re: [sr #107444] constructs generated by autoconf do not work in the ash shell

On 08/03/10 01:30, Mark Hobley wrote: > Some versions of the ash shell will not allow redirection to a stream number > held in a variable: > > # This construct does not work in some versions of the ash shell > echo $1 >&$2 What do these shells do? For example, if /bin/ash is where your ash

Re: AC_FUNC_ALLOCA shouldn't define prototype

On 08/05/10 04:26, Bruno Haible wrote: > -char *alloca (); > +void *alloca (); Thansks, I like this change too. Can you please install it?

Re: echo vs. printf regression (darwin8)

On 08/15/10 21:26, David Fang wrote: > I'm desperate enough to use sed to patch config.status after it's been > generated: If you're that desperate, you're desperate enough to use bash instead of the broken Darwin shell, no? To others: Would it be appropriate to patch Autoconf to generate a 'con

Re: AC_HEADER_STDBOOL fails with clang

On 08/23/10 09:14, Eric Blake wrote: > So does clang define __GNUC__? That's a lie, if it does not support the > same extensions as gcc. Yes, and this lie causes a lot of problems in practice: clang does not support many extensions that GCC does support. The usual workaround is to replace "define

Re: AC_HEADER_STDBOOL fails with clang

On 08/23/10 09:36, Eric Blake wrote: > gcc, where we know that the extension is supported, to make sure we > don't introduce a future regression that could have been detected by gcc > (and in case the AIX compiler is ever fixed). Well, perhaps "gratuitous" was not the right word, but there is no n

Re: [PATCH] stdbool: avoid rejecting clang

alizer, but I suppose one could argue that there's an implicit conversion to bool that would clearly be invalid if one made it explicit and wrote "(bool) &s" there. I installed this: does it help? >From 592beca18058522a3cbedceff98633b306ca80c1 Mon Sep 17 00:00:00 2001 From: P

Re: Bug or feature? checking type of readdir fails

On 08/29/2010 07:34 AM, Ville Salomäki wrote: > Problem is the opendir("/"), which gives 'false' result when the package > handler doesnt have read privileges to root. This would appear to be a bug in PHP, not in autoconf, as autoconf itself doesn't mess with readdir_r or with opendir("/").

Re: Incorrect description of YACC

26 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2010-08-29 Paul Eggert + + AC_PROG_YACC: fix comment re what "yacc" stands for + * lib/autoconf/programs.m4 (AC_PROG_YACC): YACC stands for + "Yet Another Compiler Compiler", not "Yet Another C

Re: [Bug-tar] tar 1.24: OpenBSD testsuite failures

On 10/27/10 15:07, Eric Blake wrote: > I know exactly WHY bash and other shells are trying to dup() to 10 or > greater - they MUST preserve the shell's std fds for commands after the > temporary redirection done by ': <&-'. Ah! Thanks. The light dawns. So my test was too strict. Can people ple

Re: test for basename failure

On 11/14/2010 10:31 AM, Jerker Bäck wrote: > autoconf test for basename fails for Interix (and probably all BSDs) > > libgen.h : char * basename(char* path); (POSIX standard 1003.1-2008) > > Failure is due to libgen.h is not included by the test. > Is this deliberate for some reason? autoconf it

Re: test for basename failure

On 11/14/2010 04:16 PM, Jerker Bäck wrote: > Nothing to do with autoconf then? That's right. Though they probably need to do something more complicated than what you suggest. Perhaps they should use gnulib's basename package; it should do the right thing.

Re: Detection of ISO C89 compiler

f356f9c3bd11c59f04a82d82 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 20 Nov 2010 15:26:39 -0800 Subject: [PATCH] autoconf: don't assume sys/stat.h and sys/types.h when testing C89 Problem reported by Patrick Pelissier in <http://lists.gnu.org/archive/html/bug-autoconf/2010-11/msg

Re: autotest: problem testing daemons, with possible fix

On 11/25/2010 03:24 PM, Luke Mewburn wrote: > Your patch also solves the problem. OK, thanks, I installed it. Still would appreciate another pair of eyes at some point.

Re: autotest: problem testing daemons, with possible fix

On 11/27/2010 01:28 AM, Ralf Wildenhues wrote: > Is it possible to devise an easy test case in > shell? It depends on one's definition of "easy". One complication is that some shells close fd 5 automatically; for these shells there was no bug and the fix is a no-op. Another complication is that

Re: gnulib stdint.h substitution of int64_t results in a linking error in GCC 4.(3|2|0) on OSX

On 11/27/10 00:59, Ralf Wildenhues wrote: > Should this patch have a similar pendant for the AC_TYPE_INT64_T macro > in Autoconf? Offhand I would say not, since that macro tests for int64_t individually, whereas the problem in gnulib is that all of stdint.h was being tested collectively. But perh

Re: [GNU Autoconf 2.65] testsuite: 186 failed

What happens if you run the Autoconf 2.68 test suite on your platform? Possibly the bug has been fixed since 2.65 came out.

Re: autoconf fails if env var U set

On 04/13/2011 11:02 AM, Tom Lane wrote: > If the intended use is only for ansi2knr, I'd even argue that it > should be off by default ... how many people care about ansi2knr > anymore? Nobody. It would be fine to remove the ansi2knr stuff from Autoconf.

Re: autoconf: feature request: test for GCC version

Why not stick with what you have? It may be ugly, but any Autoconfish replacement would be just as ugly, if not uglier. And what you have works now.

Re: bug in check for stack growth direction in _AC_LIBOBJ_ALLOCA

Does it work to use the following test program instead? int find_stack_direction (char *addr) { char dummy; return (! addr ? find_stack_direction (&dummy) : addr < &dummy ? 1 : -1); } int main (void) { return find_stack_direction (0) < 0; } This, essentially, is the fix I just pu

Re: bug in check for stack growth direction in _AC_LIBOBJ_ALLOCA

On 06/19/11 12:01, Andy Wingo wrote: > No, this program also exhibits the same incorrect behavior, for purposes > of stack growth checking. Thanks, I guess we'll have to turn it up a notch. How about the following test program? int find_stack_direction (int *addr, int depth) { int dir, dummy =

Re: bug in check for stack growth direction in _AC_LIBOBJ_ALLOCA

On 06/19/11 23:35, Ralf Wildenhues wrote: > If you don't use volatile, the compiler is pretty much free to give you > whatever answer it likes today. It's true that the test relies on undefined behavior, and so the compiler is free to do whatever it wants, but I don't see how adding "volatile" hel

Re: bug in check for stack growth direction in _AC_LIBOBJ_ALLOCA

On 06/21/11 12:43, Ralf Wildenhues wrote: > It would be good to make sure GCC 4.6 whole program/link time > optimization doesn't defeat this It doesn't, at least, not on my platform (Fedora 14 x86-64 + GCC 4.6.0).

Re: [GNU Autoconf 2.68] testsuite: 480 failed

On 07/23/11 12:05, Eric John Berquist wrote: > Included are logs that may be relevant Thanks, but unfortunately no logs were included in your email . Perhaps you forgot to attach them?

Re: [GNU Autoconf 2.68] testsuite: 480 failed

As near as I can make out from the files you emailed me privately, it's a bug in the MacOS X implementation of egrep (grep -E). Perhaps you can track it down by running the test "by hand", so that we can prevent spurious test failures later, but it's not high priority as it's a problem with the tes

Re: AC_C_CONST fails with -Werror

On 08/31/11 17:06, Dan Kegel wrote: > Here's a patch that seems to do the trick, only very lightly tested. Thanks. Ralf Wildenhues and Ralf Corsepius are both correct that people shouldn't be configuring with -Werror. Still, if it's bugging people it's probably worth fixing. I installed the fo

Re: On solaris, a SIGINT sent to a child process of Korn Shell kills the shell itself

On 09/12/11 05:01, Stefano Lattarini wrote: > I'd like to know if anyone has an idea of > what's going on exactly, and how (and if) I can work around it. I'd guess it's tail recursion elimination: if the last thing a Korn shell does is run another program, it bypasses the fork and does an exec dir

Re: On solaris, a SIGINT sent to a child process of Korn Shell kills the shell itself

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 POSIX

Re: On solaris, a SIGINT sent to a child process of Korn Shell kills the shell itself

On 09/12/11 13:03, Stefano Lattarini wrote: >> > It's just that this trick doesn't work for the shell itself, >> > at least, it doesn't always work in the presence of traps. >> > > So you basically agree with my opinion? I agree that it's a problem with ksh's behavior. I'm not sure that it violat

Re: Quote problem in mingw

On 09/27/11 03:31, Philip Hazel wrote: > The change looks innocuous to me I worry that the change could mask the real bug (which may lie elsewhere). For example, it could be that the previous line's backslash was interpreted incorrectly. Can you find out from the original user what the values of

Re: Fwd: Getting AC_PROG_CC_C99

On 09/28/11 01:52, Gary V. Vaughan wrote: > Might as well try to fix it right in gnulib though, and maybe in autoconf >> too if the latest release hasn't made it multi-call safe yet. The simplest fix would be something like the patch at the end of this message. This matches common practice anyway

Re: Fwd: Getting AC_PROG_CC_C99

On 09/28/11 09:45, Bruno Haible wrote: > If the package's configure.ac already invokes AC_PROG_CC_STDC, > early on (i.e. usually right after AC_PROG_CC), then gnulib's > AC_REQUIRE([AC_PROG_CC_STDC]) > will be a no-op. Ah, sorry, then we're fine as-is, since it's normal practice to put the AC_PR

Re: Getting AC_PROG_CC_C99

On 09/29/11 02:14, Bruno Haible wrote: > But switching the compiler to a different standards-compliance > mode is a global effect. I was not sure whether it would have some negative > side effects on some platforms. > > On the other hand, we do it in module 'stdarg' for 5 years now, and it has > n

Re: Getting AC_PROG_CC_C99

On 09/30/11 02:06, Bruno Haible wrote: > -- Macro: AC_PROG_CC_STDC > If the C compiler cannot compile ISO Standard C (currently C99), > ... > > sounds like this macro will then be modified to enable C1X instead of C99. Yes. > But I expect that many packages will not need this. It sho

Re: Getting AC_PROG_CC_C99

On 09/30/11 08:57, Andrew W. Nosenko wrote: > Assuming that AC_PROG_CC_C99 is not available (e.g. doesn't exists and > never existed), and only one macro is AC_PROG_CC_STDC, how I should to > express that "c99 is required"? Or "c99 or better is required"? Right now, you can't. That would need to

Re: Solaris 10 /bin/sh, shell functions, here documents and command substitutions

On 12/24/11 07:48, Stefano Lattarini wrote: > And here is a patch to document the issue. Ok for master? Thanks, please apply.

Re: Funny bug in Solaris xpg4 sh w.r.t. globbing mixed with variable expansions

On 12/24/11 08:02, Stefano Lattarini wrote: > I'm not anymore sure that this bug is worth documenting, since it is more of > a one-shot, corner-case, weirdo-looking bug rather than a more systematic > limitation or incompatibility. What do you think? Totally up to you. If you take the time to w

Re: AC_PROG_LN_S limitation

On 12/26/11 00:02, Werner LEMBERG wrote: > Can this be documented, please? Or what about making AC_PROG_LN_S > work for directories also by falling back to `cp -pr'? The latter sounds better to me, though we need to use -R not -r for better portability. Thanks for reporting the problem. I pushe

Re: Broken links in the on-line autoconf manual

On 12/26/11 12:43, Stefano Lattarini wrote: > That one's already fixed in the trunk. > This (and the others) are references to other GNU manuals. What's the rig

Re: Broken links in the on-line autoconf manual

On 12/27/11 01:07, Stefano Lattarini wrote: > I don't know how to fix those, and I was hoping to see how > you would solve your similar issues, so that I could copy your solution ;-) It turns out that the Texinfo manual itself has the same problem. So we can see what *it* does to fix this. I asked

Re: HP-UX make causes autoconf timestamp issues

That issue is now documented in the INSTALL file, as well as in the Autoconf manual. Here's the relevant commit: http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=2d082fa1ca25a16b60fb874e80f51ee79408e1f4

Re: special XLF cases not considered in _AC_PROG_FC_V_OUTPUT

Thanks for the report. I pushed a minor variation of that patch here: http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=afd2a0d7f3b88bfb058cd1c389f978acea182744

Re: Network-related functions and configuring for MinGW

As a general rule, we're trying to migrate checking for specific library features out of Autoconf and into gnulib or whereever. This is true for POSIX interfaces as well as for non-POSIX; for example, it's why AC_FUNC_FNMATCH is marked as an obsolescent macro in Autoconf. (I'd like to remove more

Re: Dealing with compilers that pretend to be GCC

On 01/19/12 06:24, Ludovic Courtès wrote: > I don’t see what can be done on “our” side (perhaps Autoconf’s feature > test could be strengthened, but how?) Which feature test would that be? I certainly understand the problem, and have run into issues where clang fools 'configure' into thinking a G

Re: AC_CHECK_SIZEOF fails with minGW

On 01/26/2012 12:09 PM, Werner LEMBERG wrote: > And indeed, manually compiling the above snippet with the given > compiler flags doesn't result in a binary! This bug is so severe that I don't think it's really an Autoconf bug, or that Autoconf should try to work around it. minGW needs to be fixed

Re: AC_CHECK_SIZEOF fails with minGW

On 01/26/2012 05:46 PM, Mike Frysinger wrote: > as a higher level response, i don't see why AC_CHECK_SIZEOF in your example > is > attempting to execute code at all. the latest autoconf is much much nicer > and > can deduce type sizes purely based on compile tests. It can, but AC_CHECK_SIZEOF

Re: [GNU Autoconf 2.68] testsuite: 419 444 failed - OSX Lion + llvm-gcc

On 02/21/2012 04:13 PM, P. Martin wrote: > This is topical because Apple just removed autoconf from the XCode-4.3 > Command Line Tools, as I'm sure you know. Hah! Like they tell us. It's news to me, but frankly it's not important news. Thanks for running the test suite. As you mention it'd be

Perl version problem in autoconf-2.68b

I tried to build Autoconf 2.68b on our production Solaris 8 sparc host (yes, we still have some in production), and the build failed as follows: autom4te_perllibdir='..'/lib AUTOM4TE_CFG='\ ../lib/autom4te.cfg' ../bin/autom4te -B '..'/lib -B '..'/li

autoconf 2.68b loops on Solaris 10 sparc (test 75)

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 with CONFIG_SHELL and it hangs until I do a ^C. "truss

Re: bug#10925: Perl version problem in autoconf-2.68b

On 03/02/2012 07:08 AM, Eric Blake wrote: > Paul, would it be okay if for autoconf we > borrow the same configure check as automake is using, and globally bump > the requirement to be consistent across the autotools? Sure. If I understand things correctly, that means 'configure' will complain tha

Re: autoconf-2.68b/tests/m4sh.at

On 03/03/2012 10:32 AM, Tim Rice wrote: > -#/bin/sh > +#!/bin/sh Thanks, I pushed that fix as follows: * tests/m4sh.at (AS@&t@_EXECUTABLE): "#!/bin/sh", not "#/bin/sh". Typo reported by Tim Rice in: http://lists.gnu.org/archive/html/autoconf-patches/2012-03/msg9.html --- tests/m4sh.at |

Re: [GNU Autoconf 2.68.147-cca28] testsuite: 100 failed

Thanks, I had already found that independently, and I fixed that by pushing the following: tests: port AS_TR_SH and AS_TR_CPP test to Solaris 8 wc * tests/m4sh.at (AS@&t@_TR_SH and AS@&t@_TR_CPP): Do not assume that "wc -l" outputs only digits; on Solaris 8 it also outputs blanks and POSIX allows

Re: [PATCH] tests: fix spurious failure due to Solaris XPG4 sh bug

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" to "script2" won't work if there happens to be a command named "s

Re: [GNU Autoconf 2.68b] testsuite: 84 failed

Perhaps you can try again with the post-2.68b patches applied? There have been several fixes in that area. I'm attaching the ones that might be relevant. diff --git a/lib/autoconf/fortran.m4 b/lib/autoconf/fortran.m4 index afeb3ab..3803595 100644 --- a/lib/autoconf/fortran.m4 +++ b/lib/autoconf/for

Re: [GNU Autoconf 2.68b] testsuite: 100 & random others failed - osx lion bash

On 03/04/2012 04:14 PM, P. Martin wrote: > ./acc.at:29: at_check_env That's checking that the test in question doesn't pollute the environment or the working directory. Basically, that the output of the 'set' and of the 'ls' commands shouldn't change. Perhaps you can look at one of the simpler lo

Re: [GNU Autoconf 2.68b] testsuite: 100 305 433 failed

On 03/05/2012 10:20 AM, Dipl. Inform. Samuel John wrote: > on OS X 10.7.3 without Xcode but with the "Command Line Tools for Xcode" > installed. Thanks, could you please try it again with the following patches, and let us know how that works? http://lists.gnu.org/archive/html/bug-autoconf/2012-

Re: [GNU Autoconf 2.68b] testsuite: 100 251 285 286 failed

guard's expectations. Reports by Tim Rice and Paul Eggert. * lib/m4sugar/m4sh.m4 (_AS_LINENO_PREPARE): Export '_as_can_reexec' to "no" before sourcing the just-created configure.lineno. --- lib/m4sugar/m4sh.m4 |4 1 files changed, 4 insertions(+), 0 deletions(-)

Re: [GNU Autoconf 2.68b] testsuite: 454 479 failed

Could you look in one of the offending directories (tests/testsuite.dir/454, say), and check whether the state-env.before and state-env.after files actually differ? Or perhaps it'd be easier if you just emailed us a compressed tarball of tests/testsuite.dir.

Re: [GNU Autoconf 2.68] testsuite: 1 10 11 12 14 16 17 20 22 24 25 27 28 32 33 36 38 208 211 212 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 231 232 233 234 235 236 237 238 239 240

That sure is a lot of test failures. Can you please try our latest Autoconf beta? It has some fixes in this area. ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.68b.tar.gz I suggest applying these post-2.68b patches as well: http://lists.gnu.org/archive/html/bug-autoconf/2012-03/txtmjhqa66pjL.txt

Autoconf-2.68b possible patch for FreeBSD, MacOS X

2156a From 449ba82926d076abaf344d999ef0ab1fdad04040 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 6 Mar 2012 22:56:39 -0800 Subject: [PATCH] tests: port AT_CHECK_ENV to hosts with flaky grep * tests/local.at (AT_CHECK_ENV): Don't assume that if one grep fails, the other will too. It coul

<    1   2   3   4   5   6   >