Tim Blechmann [EMAIL PROTECTED] writes:
my configure.in file contains:
AC_CHECK_LIB(m,sin)
Could you please send a complete, self-contained test case, and
mention which version of Autoconf (and other software) you're using?
things. I installed this patch:
2005-04-10 Paul Eggert [EMAIL PROTECTED]
* doc/autoconf.texi (Particular Functions): Use gnulib's current
pattern for alloca snippet.
Index: autoconf.texi
===
RCS file: /cvsroot
for now. I installed this:
2005-05-25 Paul Eggert [EMAIL PROTECTED]
* tests/local.at: Don't attempt to check for negated character
classes in shell scripts. The test was too brittle.
--- local.at.~1.15.~2005-05-24 09:46:35 -0700
+++ local.at2005-05-25 11:29:38 -0700
Thanks for the patch; I installed it.
[EMAIL PROTECTED] (Karl Berry) writes:
I'd also like to suggest outputting some kind of marker before each
configuring line, if there's a portable way to do so, so that
Emacs page commands can do something useful. (There are thousands
of lines of output in my case and anything to help
Gour [EMAIL PROTECTED] writes:
The question remains: how to easily solve the problem of invoking custom
'configure' script in one of the sub-package directories?
What I'd do is put the sub-package one level further down, and
use my own configure.ac that generates a configure that invokes
the
Hrvoje Niksic [EMAIL PROTECTED] writes:
I'm now using this:
#if HAVE_ALLOCA_H
# include alloca.h
#elif defined _MSC_VER || defined __BORLANDC__ || defined __MINGW32__
# include malloc.h
#elif defined __GNUC__
# define alloca __builtin_alloca
#elif defined _AIX
# define alloca __alloca
Hrvoje Niksic [EMAIL PROTECTED] writes:
Paul Eggert [EMAIL PROTECTED] writes:
This doesn't look right to me, because if _MSC_VER is defined, it
includes malloc.h without the # define alloca _alloca line that
other people seem to have needed.
I haven't needed that line in Wget. Maybe
Nicolas Joly [EMAIL PROTECTED] writes:
+configure: loading site script /usr/local/share/config.site
It looks to me like you have a config.site that defines LIBS.
That might explain the test failures. Can you try removing it
and testing again?
Akim Demaille [EMAIL PROTECTED] writes:
The Autotools currently quite promote using `bison -y' (so that the
file naming conventions are those of Yacc). Autoconf and Automake
should be upgraded to support native Bison in addition of stupid
yacc names.
For Autoconf, this would be done by
Mikulas Patocka [EMAIL PROTECTED] writes:
Intel compiler's interprocedural optimizations (-ipo) optimizes this
out even though the symbol is unknown.
Wonderful. (:-)
I installed the following patch to try to catch this.
2005-10-19 Paul Eggert [EMAIL PROTECTED]
* doc/autoconf.texi
Mikulas Patocka [EMAIL PROTECTED] writes:
The compilation gets a bit further with the patch, but it still
doesn't work --- this time it is problem of intel compiler --- it
can't extract its intercode from *.a files.
The Intel compiler mishandles static libraries? That sounds like
a real
Stepan Kasal [EMAIL PROTECTED] writes:
Both do, but trap '' 0 seems to be the most portable.
And it is also the clener one.
Proposed patch attached.
Thanks. I installed that (replacing trap - 0 with trap '' 0 in
install-sh) into Automake's main line. Perhaps it should be put into
a
Thanks, Ralf; can you please install those two patches?
Werner LEMBERG [EMAIL PROTECTED] writes:
I suggest to add that `\?', `\+', and `\|' should not be used in sed
expressions
Thanks for suggesting that. The problem is a bit more general, so I
installed the following:
2005-12-12 Paul Eggert [EMAIL PROTECTED]
* doc/autoconf.texi
Thanks for reporting this and diagnosing it. I installed this to
work around the problem. Perhaps there's a better fix, but I hope
this works around the problem anyway.
2006-03-08 Paul Eggert [EMAIL PROTECTED]
* tests/c.at (AC_PROG_CPP without warnings, AC_PROG_CPP via CC
Linda W [EMAIL PROTECTED] writes:
I believe bash is broken in regards to using any number after
\ as an octal value. The shell specifications require the leading
zero for an octal constant
I'm afraid this is backwards. This POSIX+XSI requirement constrains
applications, not implementations.
Ralf Wildenhues [EMAIL PROTECTED] writes:
OK, so I removed the generated *.at files from the CVS.
Please undo that. The creation of these files is not portable:
But these files aren't intended to be built by installers, so that
shouldn't matter.
We are close to an alpha release, but not
Ralf Wildenhues [EMAIL PROTECTED] writes:
Oh, I certainly would not mind a nicer patch.
Likewise. Given that the patch fixes real problems, I suggest
installing it and waiting for the nicer fix later.
Stepan Kasal [EMAIL PROTECTED] writes:
I second this proposal. I think this could be added right now, even though
we are in a freeze.
I tend to agree, since it's taken from Automake. Assuming my minor
patch to Automake for leading - is accepted I'd like that change put
into Autoconf as well.
Bruno Haible [EMAIL PROTECTED] writes:
Thanks. The problem exists in MacOS X 10.3.9 (the final version of the 10.3
series) and is fixed already in 10.4.3. Here is a patch.
Thanks, I installed that.
Bruno Haible [EMAIL PROTECTED] writes:
ISO C 99, section 6.2.5 paragraph 17, defines the term integer types:
The type char, the signed and unsigned integer types, and the enumerated
types are collectively called integer types.
So, _Bool and bool are _not_ integer types.
No, because
Fedor Sergeev of Sun pointed out that my analysis of (bool) -0.5 as an
integer constant expression was incorrect, as the - isn't allowed in
C99. I installed this fix into gnulib and coreutils (and a similar
fix into autoconf).
2006-05-14 Paul Eggert [EMAIL PROTECTED]
* stdbool.m4
Ralf Wildenhues [EMAIL PROTECTED] writes:
The config.status special magic from this patch:
http://lists.gnu.org/archive/html/autoconf-patches/2006-05/msg00041.html
doesn't work if we don't also use a program with an absolute name.
What's the bug with it? Sorry, I don't follow.
OK to apply
Thanks for the bug report. I suspect that the sed usage is portable
but that we are running into some limitation of your 'sed'
implementation.
Here is some further information that you can send that will help us
debug this. (I don't have access to your platform so I can't debug
the problem
ones.
2006-05-19 Paul Eggert [EMAIL PROTECTED]
* lib/autoconf/status.m4 (_AC_OUTPUT_HEADER): Fix off-by-one bug
that caused config.status to generate 100-command sed scripts; the
portable limit is 99.
--- lib/autoconf/status.m4 19 May 2006 04:14:13 - 1.102
Re http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=368012,
Ralf Wildenhues [EMAIL PROTECTED] writes:
http://lists.gnu.org/archive/html/autoconf-patches/2006-04/msg00027.html
... broke this.
I'm still wondering whether we should just simply revert both patches,
... and leave a cleanup of
that this patch removes the undocumented
ac_word_regexp var. That was a fairly recent addition, though (June
2005), and I couldn't find evidence in Google of other packages using
it.
2006-05-23 Paul Eggert [EMAIL PROTECTED]
* lib/autoconf/status.m4 (_AC_OUTPUT_HEADER): Don't use shell
Vincent Lefevre [EMAIL PROTECTED] writes:
I don't know if it has been fixed upstream...
It has.
Ralf Wildenhues [EMAIL PROTECTED] writes:
* lib/autoconf/functions.m4 (AC_FUNC_ALLOCA): Work around
`unused variable' compiler warning, for `-Wall -Werror'.
Report by Jaap Haitsma [EMAIL PROTECTED].
Yes, that looks fine. Thanks.
Thanks; could you try that with test version 2.59d instead? We're
planning to release a new official version soon. I think we've fixed
your problems but it'd be nice to check it.
ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.59d.tar.gz
Thanks.
Tollef Fog Heen [EMAIL PROTECTED] writes:
Apart from the «ewww» factor, why can't it do its work in a subshell
and echo back the parameters to be set and those get eval-ed by
configure?
Yes, something like that might work, given that you know the values
can't contain ' (though you should
Ralf Wildenhues [EMAIL PROTECTED] writes:
* lib/autoconf/types.m4 (_AC_TYPE_UNSIGNED_INT): Solaris 2.5.1
needs _UINT8_T and _UINT64_T defines as well, to avoid clashes
with system headers. Report by Bruno Haible.
That looks good; please install, since it's clearly an
Ralf Wildenhues [EMAIL PROTECTED] writes:
* lib/autoconf/types.m4 (_AC_TYPE_INT): Set `$ac_cv_c_int$1_t'
to `yes' instead of `int$1_t' if the type is found, for more
consistent configure output (where $1 is the number of bits).
(_AC_TYPE_UINT): Likewise for `uint$1_t'.
Ralf Wildenhues [EMAIL PROTECTED] writes:
The difference being that the existing heuristic has been tested
on about a dozen platforms and is thus less likely to break due
to, say, some obscure sed limitation on some platform.
OK, but the new test he added (marked '+' below):
{ ac_out=`sed
[EMAIL PROTECTED] (Larry Jones) writes:
The IBM C compiler for AIX has a default mode that's almost, but not
quite, C89. The differences mostly involve the preprocessor. In
particular, macro parameters are substituted inside character constants
and string literals, which can be quite
Thanks for the bug report. I installed this patch:
2006-06-30 Paul Eggert [EMAIL PROTECTED]
* tests/torture.at (Configuring subdirectories): Set CONFIG_SITE
to a nonexistent file, so that we don't have to worry about
a local site configuration that doesn't use /usr
Could you please test Autoconf 2.60 rather than 2.59? That might fix
the problem. Also, as Stepan Kasal notes, you should upgrade Automake
as well; Automake 1.4 is over 7 years old.
Ralf Wildenhues [EMAIL PROTECTED] writes:
Looks ok to me (untested). Doesn't Autotest though guarantee that each
test runs in its own subshell, saving you from the need to unset,
I didn't know that. OK, thanks, I installed the following simpler
patch instead.
--- torture.at 23 Jun 2006
and CFLAGS is not passed to preprocessor-only invocations. In
retrospect this was probably a bad design decision, but changing this
will be painful.
I installed the following patch into the Autoconf documentation to try
to explain things better.
2006-07-20 Paul Eggert [EMAIL PROTECTED]
* doc
2006-07-24 Paul Eggert [EMAIL PROTECTED]
* doc/autoconf.texi (Limitations of Usual Tools): Warn about
sed stripping leading white space from text. From Bruno
Haible.
Thanks for mentioning that. I installed the following
slightly-different patch.
--- autoconf.texi
Thanks for the bug report. You can apply the following patch:
http://lists.gnu.org/archive/html/autoconf-patches/2006-07/msg00028.html
g95 compiler create?
I installed the following patch to fix the other bugs noted in your
report. Thanks again.
2006-08-06 Paul Eggert [EMAIL PROTECTED]
Fix test suite failures reported by Pierre in
http://lists.gnu.org/archive/html/bug-autoconf/2006-08/msg5.html
to Autoconf so that the workaround shouldn't be needed in the
future.
2006-08-25 Paul Eggert [EMAIL PROTECTED]
* doc/autoconf.texi (Particular Programs): YYTEXT_POINTER is
for the default, which the user can override.
* lib/autoconf/programs.m4 (AC_PROG_LEX): Let
Tim Rice [EMAIL PROTECTED] writes:
I have no idea why SESEOF is there instead of _ASEOF
It's probably some bug in the Unixware shell. You might be able to
use the truss command to verify this. If we knew more about the
bug, we might be able to work around it.
. The area is kind of messy, but I guess it's better to let
the OSF and Unixware folks figure out how to build than to hurt
everyone else.
2006-10-04 Paul Eggert [EMAIL PROTECTED]
* doc/autoconf.texi (Special Shell Variables): Autoconf-generated
shell scripts no longer export BIN_SH
Thanks for the bug report. That is a bug in the test suite, not
Autoconf itself, so you should be fine.
Alex Unleashed [EMAIL PROTECTED] writes:
- if $mkdirprog -m $test_mode -p -- / /dev/null 21; then
+ if $mkdirprog -m $test_mode -p -- . /dev/null 21; then
Sorry, but this fix causes install-sh to deduce the wrong
answer if the working directory is not searchable.
Currently the test
(/, ...) is? This doesn't
sound consistent to me; both system calls _attempt_ to write to an
external file name. And neither _succeeds_ (which is what should
matter here). So it sounds like your sandbox tests should be
adjusted, one way or another, since they're not consistent.
2006-10-09 Paul Eggert [EMAIL
Here's a proposed patch to Automake to work around the FreeBSD mkdir
bug described in
http://lists.gnu.org/archive/html/bug-autoconf/2006-10/msg00012.html
2006-10-09 Paul Eggert [EMAIL PROTECTED]
* lib/install-sh (posix_mkdir): Reject FreeBSD 6.1 mkdir -p -m,
which incorrectly
(that's what the rest of the script
does). So here's a revised patch.
2006-10-10 Paul Eggert [EMAIL PROTECTED]
* lib/install-sh (posix_mkdir): Reject FreeBSD 6.1 mkdir -p -m,
which incorrectly sets the mode of an existing destination
directory. In some cases the unpatched
Alex Unleashed [EMAIL PROTECTED] writes:
the fact of the attempt is what
really matters,
I'm afraid I'll have to disagree on this one, as a matter of
philosophy. Autoconf regularly tries stuff to see whether it works.
It's not at all unreasonable for Autoconf to try programs that have
memory
Stepan Kasal [EMAIL PROTECTED] writes:
To sum up: I suggest to accept 1), 2) and reject 3), 4).
Since 1) and 2) are not controversial I installed them.
I'll address 3) and 4) later.
I also installed this NEWS item:
--- NEWS26 Sep 2006 20:43:00 - 1.402
+++ NEWS11 Oct
this patch instead; it preserves the semantics of
AS_EXECUTABLE_P and adds a new macro AS_TEST_X that behaves like test -x.
2006-10-11 Paul Eggert [EMAIL PROTECTED]
* lib/m4sugar/m4sh.m4 (AS_TEST_X): New macro.
(AS_EXECUTABLE_P): Use as_test_x rather than as_executable_p
Stepan Kasal [EMAIL PROTECTED] writes:
4) Use AS_EXECUTABLE_P in _AS_DETECT_BETTER_SHELL.
(See autoconf-20061009-bin-sh-4.patch, also attached.)
This depends on 3) and introduces problems reported by Ralf.
I don't recall what those problems were. I guess some circularity
issues? Anyway,
Stepan Kasal [EMAIL PROTECTED] writes:
2) On ancient systems, the old `test -f' was ``good enough''
approximation,
But I thought the whole problem was that people were putting
directories named 'perl' in their path.
To some extent you're right, it's not a big deal. It just really
bugged me
Thanks for reporting those problems. Test 3 failed due to a bug
in the Autoconf test suite; you can ignore that failure safely.
Test 130 failed, I think, because GNU Fortran wasn't installed
correctly on your host; I wouldn't worry about that unless you
use Fortran.
Peter Simons [EMAIL PROTECTED] writes:
My suggestion is to change that paragraph to read as follows:
| pThird party macros can be downloaded from the a
| href=http://autoconf-archive.cryp.to/;Autoconf Macro
| Archive/a./p
...
the THANKS file does have on obsolete e-mail address for me:
Bruno Haible [EMAIL PROTECTED] writes:
I think this qualifies as a portability pitfall. How about documenting it?
Thanks. I installed the following slightly-more-general change.
2006-10-24 Paul Eggert [EMAIL PROTECTED]
* doc/autoconf.texi (Limitations of Usual Tools): Document
Ralf Wildenhues [EMAIL PROTECTED] writes:
-configure.ac:19:TRACE1:foo bar:bar foo
+configure.ac:16:TRACE1:foo bar:bar foo
Thanks for reporting that. I installed the following to pacify
Autoconf 'make check' for now. I suppose we can install a better
check later.
2006-10-24 Paul Eggert
Jeph Cowan [EMAIL PROTECTED] writes:
Attached is the testsuite.log file with more info on the failed
tests. Also note that the 'make check' was started at 8:28AM and
finished the following morning at 00:46, some 16+ hours later. Am I
doing something wrong?
It does look like there is a little
: error: invalid type argument of 'unary *'
foo.c:22: error: expected expression before ')' token
1
For now, I'll assume that it does not compile, and so I installed the
following patch, but I'd like you to verify my assumption. Thanks.
2006-10-26 Paul Eggert [EMAIL PROTECTED
Sergei Steshenko [EMAIL PROTECTED] writes:
I am building autoconf-2.60 in the framework of my project (see signature) and
'make check' fails - just several tests.
Actually, it's just one test (test 3) that fails, and it's not a
failure I'm familiar with offhand.
A couple of things to try:
Bruno Haible [EMAIL PROTECTED] writes:
I think the right implementation
would be a library of shell functions.
Thanks. That's the right direction for Autoconf in general, one that
we've long had sentiment to explore -- but not the resources.
Thanks for that suggestion and patch. I installed the following; it's
the same as your proposal except I added a NEWS item and tweaked another
sentence in the documentation.
2006-11-13 Paul Eggert [EMAIL PROTECTED]
* NEWS: Document the AC_ARG_WITH change.
2006-11-13 Bruno Haible
We're happy to announce the release of Autoconf 2.61.
Please grab it from one of the gnu.org mirror sites.
The important changes since 2.60 are listed below. The BIN_SH change
may require special attention by installers on some older-style
platforms, but as far as we know this affects only
Sim Byoungsoo [EMAIL PROTECTED] writes:
./torture.at:1057: autoreconf -Wall -v -i
...
autoreconf: running: automake --add-missing --copy
automake: configure.in: installing `./install-sh'
error while copying
That message comes from Automake. Which version of Automake are you
using? Run
Ralf Menzel [EMAIL PROTECTED] writes:
A recent checkout of autoconf fails for me at test 287.
Thanks for reporting that. I installed this patch:
2006-12-01 Paul Eggert [EMAIL PROTECTED]
* tests/mktests.sh (ac_exclude_list): Exclude AC_FUNC_SETVBUF_REVERSED.
* tests
Tim Van Holder [EMAIL PROTECTED] writes:
when building sed 3.1.5 I ran into the following problem:
configure correctly detected that mingw32 has alloca but
no working alloca.h; however, regex-internal.h simply
includes alloca.h unconditionally, breaking the build.
Surely this is because sed
Chris McGuire [EMAIL PROTECTED] writes:
To get m4 to build on my old BSDI 4.0.1 machine
Hmm, that's software from a company (BSDI) that exists no longer. And
the company's successor (Wind River Systems) discontinued support for
BSD/OS at the end of 2004. Our usual rule is to not worry about
Chris McGuire [EMAIL PROTECTED] writes:
Wasn't the output of the build process that I sent along originally (showing
where it failed) an example?
Sorry, no, as the output doesn't contain a test program.
if autoconf or configure could be tweaked in future
versions to apply what appears to
in case
someone tries to do it anyway. I installed the following.
2006-12-15 Paul Eggert [EMAIL PROTECTED]
This change prompted by a problem report by Andrey Simonenko in
http://lists.gnu.org/archive/html/bug-autoconf/2006-12/msg00026.html.
* doc/autoconf.texi (Defining
Ben Pfaff [EMAIL PROTECTED] writes:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403243
Thanks, I installed that into Autoconf. Here's the patch
again, for autoconf-patches:
2006-12-15 Paul Eggert [EMAIL PROTECTED]
* lib/autoconf/functions.m4 (AC_FUNC_GETMNTENT
Ralf Wildenhues [EMAIL PROTECTED] writes:
I'm thinking of something along these lines:
mkfifo at-fifo-err
mkfifo at-fifo-out
command='{ sleep 2; echo out ; echo err 2; sleep 2; exit 42; }'
( exec at-fifo-out 2at-fifo-err ; eval $command ) at_cmd1=$!
tee at-fifo-out stdout
Ian Macdonald [EMAIL PROTECTED] writes:
Consistant failure of this test after rebuilding Sed-4.1.5 and
Autoconf-2.61 several times. Standard configure of Sed, building Linux
From Scratch in chroot.
Is this serious?
Sounds bad to me, yes. I can't reproduce the problem with sed 4.1.5
that I
Ralf Wildenhues [EMAIL PROTECTED] writes:
Is it right that POSIX requires all these broken pipe errors when the
reader closes early, before all output is consumed?
I don't see where POSIX requires that behavior, but perhaps I'm not
looking at the right part of POSIX.
Inge Witsoe [EMAIL PROTECTED] writes:
when installing autoconf 2.59 (I already have autoconf 2.60 installed, but I
need 2.59 when trying to cross-compile GMP to a MSP microcontroller) I get 4
failed tests when running 'make check' (see attached log file).
Autoconf 2.59 is frozen, so perhaps
AC_DEFINE([DEF(x)], [somevalue])
Ouch! That's not supported, and I'm surprised you got it to work as
well as it did.
status.m4 contains a code which supports this, so until now I had no
idea that this may be deprecated. I think this feature was available
since the beginning of
Georg Schwarz [EMAIL PROTECTED] writes:
sure, but in that case it would make sense to have configure not fail
if -e does not work, or not to check for it in the first place.
Autoconf could probably be modified to prefer a grep that supports -e
to one that does not. But I'm not sure why it
[EMAIL PROTECTED] writes:
One difference I noted in the test code used between tar-1.16.1 and
findutils-4.2.29 (2.60 vs 2.60a) was:
tar: s = re_compile_pattern (a[[:]:]]b\n, 11, regex);
findutils: s = re_compile_pattern (a[:]:]b\n, 9, regex);
A printf in both shows that tar says
Steven G. Johnson [EMAIL PROTECTED] writes:
(In fact, I believe I'm the one who originally patched autoconf to
support macro arguments in AC_DEFINE.)
That could well be, but it was never documented and it's not clear
to me what the semantics would be. Are arbitrary characters allowed
in the
Steven G. Johnson [EMAIL PROTECTED] writes:
why not say that the characters must be in
[A-Za-z0-9_,()], and must form a valid cpp identifier and (optionally)
a valid cpp argument list?
That's a reasonable restriction, except
(Ellipses are a C99 feature and it would not be a good idea to
OK, thanks, I installed that, after tightening up the documentation
a bit. Here's the documentation patch I installed.
--- autoconf.texi.~1.1120~ 2006-12-28 22:17:02.0 -0800
+++ autoconf.texi 2006-12-28 22:40:28.0 -0800
@@ -8252,8 +8252,15 @@ output.
@defmacx
Today I updated the Autoconf manual to contain the following
description of the current situation with signed integer overflow.
This section of the manual is intended to advise programmers what to
do about portable C programs in this area.
I think some discussion along these lines also belongs in
[EMAIL PROTECTED] (Richard Kenner) writes:
Many portable C programs assume that signed integer overflow wraps around
reliably using two's complement arithmetic.
I was looking for an adjective that mean the programs work on a wide
variety of platforms, and portable seems more appropriate
reliable)
2007-01-02 Paul Eggert [EMAIL PROTECTED]
* doc/autoconf.texi (Integer Overflow): Revised based on today's
feedback. The most important changes document what happens when
you convert an out-of-range value to a signed integer type, and
say that (sum
Andrew Pinski [EMAIL PROTECTED] writes:
the one thing I have not heard through this
discussion is the real reason why the C standards comittee decided
signed overflow as being undefined.
I wasn't there, but my impression is that many of the optimization
issues we've talked about in this
I cannot reproduce the problem on my Solaris 8 (sparc) host.
I notice yours hasn't been patched for a while (e.g., kernel patch
117350-08), whereas mine is a bit more up to date (117350-38). Dunno
if that matters.
Perhaps you might truss it and see which process is getting
the broken pipe.
Stepan Kasal [EMAIL PROTECTED] writes:
-* autoconf: (autoconf)autoconf Invocation.
+* autoconf invocation: (autoconf)autoconf Invocation.
How to create configuration scripts
That's fine with me.
Stepan Kasal [EMAIL PROTECTED] writes:
2007-01-15 Stepan Kasal [EMAIL PROTECTED]
* doc/autoconf.texi (Specifying Names): `--host' does not
change the build type.
Looks good to me; please install. Thanks.
Ralf Wildenhues [EMAIL PROTECTED] writes:
-is called. The value can contain newlines.
+is called. The value can contain all ASCII characters except for
+the @code{NUL} character and carriage return; newline is ok to use.
If we can assume POSIX conformance with a reasonable C locale, the
Ralf Wildenhues [EMAIL PROTECTED] writes:
I'm a bit afraid this warning in autoconf.info(File Descriptors):
|Don't rely on open file descriptors being open in child processes.
| In `ksh', file descriptors above 2 which are opened using `exec Nfile'
| are closed by a subsequent `exec'
Jonathan Schleifer [EMAIL PROTECTED] writes:
-autom4te: $(srcdir)/autom4te.in
+autom4te $(top_builddir)/bin/autom4te: $(srcdir)/autom4te.in
Could you please explain why the patch is needed? autom4te and
$(top_builddir)/bin/autom4te are the same file, so why is it necessary
to mention it by
I have installed the following patch into Autoconf in an attempt to
fix the problem. However, I have not tested this under Mac OS X, so
it'd help if someone with access to that environment could test it.
2007-02-27 Paul Eggert [EMAIL PROTECTED]
* NEWS: AC_C_BIGENDIAN now supports
Hiroyuki NISHIMURA [EMAIL PROTECTED] writes:
I am afraid that I think Sun's sed is No Good, GNU sed is Good.
I cannot reproduce the problem on my Solaris 9 sparc host. Perhaps
you need to patch your Solaris installation? Here's the 'sed' I have:
136-pete $ ls -l /usr/bin/sed
-r-xr-xr-x 1
it a try when you have the time.
2007-02-28 Paul Eggert [EMAIL PROTECTED]
* lib/autoconf/c.m4 (AC_C_BIGENDIAN): Fix typo __LITLE_ENDIAN__.
Problem reported by Paolo Bonzini in:
http://lists.gnu.org/archive/html/autoconf-patches/2007-02/msg00024.html
* tests
Peter O'Gorman [EMAIL PROTECTED] writes:
There are quite a number of software packages
out there that do not use config headers for whatever reason.
OK, thanks, I installed this:
2007-03-05 Paul Eggert [EMAIL PROTECTED]
* doc/autoconf.texi (C Compiler): Warn that AC_C_BIGENDIAN
Stepan Kasal [EMAIL PROTECTED] writes:
So the question is whether we should keep the documented behavior,
or whether we should change the specification and break compatibility
with the recent releases.
I'd rather add the feature in a nice, documented way. Possibly there
should be another
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 string.h work.
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: doc/autoconf.texi
1 - 100 of 352 matches
Mail list logo
