Nick Bowler wrote:
> > Note: I think POSIX [1] mandates the behaviour of OpenBSD and Solaris sed.
> > But that is not immediately relevant for the Autoconf manual: The
> > portability
> > problem exists regardless of how we might interpret POSIX.
>
> The GNU behaviour is likely non-conforming wit
uno
[1] https://pubs.opengroup.org/onlinepubs/9799919799/utilities/sed.html
>From 8b043c4d205620687b7635d40a599c9bc16c6e2f Mon Sep 17 00:00:00 2001
From: Bruno Haible
Date: Mon, 23 Jun 2025 23:29:29 +0200
Subject: [PATCH] doc: Document another portability pitfall of sed.
* doc/autoconf.texi
In doc/autoconf.texi, around line 8680, the line
+@code{A68FLAGS} may be set before @code{AC_PROG_A68}l
is not properly terminated. Maybe just a typo?
Bruno
Hi,
Reply to this mail thread:
https://lists.gnu.org/archive/html/autoconf-patches/2025-01/msg00014.html
https://lists.gnu.org/archive/html/autoconf-patches/2025-01/msg00015.html
https://lists.gnu.org/archive/html/autoconf-patches/2025-01/msg00016.html
https://lists.gnu.org/archive/html/autoconf-p
Paul Eggert wrote:
> Thanks, I installed that, along with the attached followup which
> documents some other globbing pitfalls.
Thanks. That's much more complete!
> By the way, brace expansion is not part of globbing: it's a prepass over
> the shell command and it operates independently of file
able Shell Programming" chapter,
to mention it.
>From ace49a2691d82a027acd76787ce3508ae1fa9b9c Mon Sep 17 00:00:00 2001
From: Bruno Haible
Date: Tue, 6 May 2025 09:57:56 +0200
Subject: [PATCH] doc: Document another pitfall of shell pattern matching.
* doc/autoconf.texi (Shell Pattern Matc
Zack Weinberg wrote:
> > https://git.savannah.gnu.org/gitweb/?p=config.git;a=commitdiff;h=91f6a7f616b161c25ba2001861a40e662e18c4ad
> >
> > https://git.savannah.gnu.org/gitweb/?p=config.git;a=commitdiff;h=28ea239c53a2d5d8800c472bc2452eaa16e37af2
> > the host_os values windows* (and in particular win
u.org/archive/html/autoconf-patches/2023-08/msg5.html>;
no changes are needed after the second config.git commit mentioned above.
>From 7f6fbae6de7b0dff850dbab99d290f54b4bcda06 Mon Sep 17 00:00:00 2001
From: Bruno Haible
Date: Thu, 17 Aug 2023 15:44:05 +0200
Subject: [PATCH] Recognize the
patch does the necessary things on the Autoconf side, by accepting a
host_os of the form windows* anywhere where mingw* is accepted.
>From 7f6fbae6de7b0dff850dbab99d290f54b4bcda06 Mon Sep 17 00:00:00 2001
From: Bruno Haible
Date: Thu, 17 Aug 2023 15:44:05 +0200
Subject: [PATCH] Recognize the *-*
of review, find also the HTML-formatted
chapter: `makeinfo --html --no-split install.texi`.
>From c97bcff8c41b297fc408d6935133aa4616724030 Mon Sep 17 00:00:00 2001
From: Bruno Haible
Date: Fri, 23 Jun 2023 17:37:35 +0200
Subject: [PATCH] INSTALL: Clarify --build, --host, --target, and the system
Jim Meyering wrote:
> this snapshot really was built with
> the very latest autoconf from master. Compare with grep-3.9, which
> was bootstrapped using a version of autoconf from October.
> ...
> grep snapshot:
> https://meyering.net/grep/grep-ss.tar.xz 1.7 MB
> https://meyering.net/grep/g
and BusyBox 'join' in the same chapter.
>From daee95145afac43c083a50c5d9f17283338737fb Mon Sep 17 00:00:00 2001
From: Bruno Haible
Date: Fri, 3 Mar 2023 14:32:13 +0100
Subject: [PATCH] Document limitation of BusyBox tr.
BusyBox 1.35.0 tr, which is shipped with Alpine Linux 3.17, does not support
the POSIX [x
Alfred M. Szmidt wrote:
>>The configure --help output and/or the documentation should state that
>> - "make install" will install into SYSCONFDIR,
>
> It should absolutley not state that. It is on purpose that `make
> install' does not trash sysconfdir
Well, at least 178 packages do ins
Jason Sikes wrote:
> You are correct that the
> configuration files should only go in one directory when done on behalf
> of a distribution.
OK, this removes my biggest worry.
> >* worse, invites packages to (perhaps inadvertently) restrict user
> > freedom.
>
> Restricting user freedom i
> On 2023-02-06 08:30, Valentin Lefebvre wrote:
> > This patch add a new autoconf argument that allows installation
> > into the vendor configuration directory (/usr/etc/). Some linux
> > distribution now move system configuration files from /etc to /usr/etc.
> > See this ref: [0]
>
> > [
Sam James wrote:
> Perhaps we could tag an RC and shove it into the platform-testers list?
platform-testers is not a wide enough audience. I'd suggest to write to
gnu-prog-discuss and ask some of the maintainers there to try to upgrade
their packages to the Autoconf RC.
Bruno
toconf.git;a=commitdiff;h=d405fa2ec63b0e4ebb9f84d1a4b2a6de63b2d26d
>From 7ff005398286f055db84364205ff30a2eee04f71 Mon Sep 17 00:00:00 2001
From: Bruno Haible
Date: Sat, 8 Jan 2022 22:31:58 +0100
Subject: [PATCH] doc: Document how to deal with missing 'join'.
* doc/autoconf.texi (Limitations of Usual Tools): Men
Here's a patch to mention a portability problems of 'od', that I noticed
during Gnulib work.
>From 4ab7b8f2cd39ee22c17cd8a7b3030d1082e3167d Mon Sep 17 00:00:00 2001
From: Bruno Haible
Date: Tue, 29 Dec 2020 03:38:31 +0100
Subject: [PATCH] doc: Document another portabil
entation should be enhanced to avoid this
misinterpretation.
Proposed patch attached.
Bruno
From 11b827d202aa07b2b8c8f894d8f49844d570dfe9 Mon Sep 17 00:00:00 2001
From: Bruno Haible
Date: Tue, 6 Oct 2020 23:46:42 +0200
Subject: [PATCH] Clarify that AS_IF and AS_CASE are overkill inside AC_DEFUN.
* doc/autoconf.texi (Comm
Zack Weinberg wrote:
> I verified both of these behaviors and merged the patch, with two
> slight changes to the text:
>
> - it is specifically Solaris 10 /bin/sh that executes redirected
> compound commands in a subshell; ksh (aka /usr/xpg4/bin/sh) doesn't.
> - the latest version of dash also d
10.
Mention that a known problem also occurs in dash.
>From e41b8b2b2a59ee765e2c7b583be68101c2da52eb Mon Sep 17 00:00:00 2001
From: Bruno Haible
Date: Fri, 18 Sep 2020 01:17:38 +0200
Subject: [PATCH] doc: Mention two more shell portability problems.
* doc/autoconf.texi (File Descriptors): Men
Oops, I withdraw 0003. (I had misunderstood what AC_FUNC_MMAP does.)
Please use this one instead.
>From f3f0bc607012a8f30a674000b570ef85433ecc74 Mon Sep 17 00:00:00 2001
From: Bruno Haible
Date: Fri, 31 Jul 2020 13:26:04 +0200
Subject: [PATCH 3/3] doc: Update some more macro descripti
ros, where Gnulib has
significant workarounds.
- 0003 updates the documentation also for macros for which no corresponding
Gnulib module exists.
Bruno
>From 316e468f0b6d251ab07ffc00c075dc7a7bad7b0f Mon Sep 17 00:00:00 2001
From: Bruno Haible
Date: Fri, 31 Jul 2020 13:15:50 +0200
Subject: [PATCH 1
iff is now GNU wdiff again, see
http://ftp.gnu.org/gnu/wdiff/
Here's a proposed patch.
2016-12-14 Bruno Haible
* doc/autoconf.texi (Using Autotest): Stop mentioning Free Recode.
Free Wdiff is now GNU Wdiff again.
--- doc/autoconf.texi.orig 2016-11-07 17:28:1
rks=no)])
+ [case "$host_os" in # ((
+ # Guess yes on glibc systems.
+ *-gnu*) ac_cv_func_strcoll_works=yes ;;
+ # If we don't know, assume the worst.
+ *) ac_cv_func_strcoll_works=no ;;
+ esa
Thanks Eric for applying the patches.
Eric Blake wrote to Peter Rosin:
> Maybe you are right that a knob to force
> build!=host mode even when the non-native binaries can be run, in order
> to use that knob to eliminate the surprises due to Wine, is worth adding
Such a knob already exists and is
Peter Rosin wrote:
> It is clearly confusing that you get different behavior by
> explicitly specifying a default value.
Yes, and documentation can help people to understand this.
> Bruno thinks it is bad to enter cross-compile mode when the build
> system can execute host code
More precisely, I
in" --host=i586-pc-mingw32
configure: WARNING: If you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used.
checking build system type... i686-pc-cygwin
checking host system type... i586-pc-mingw32
configure: cre
Peter Rosin wrote:
> it is wrong, it is a cross compile
I don't want to discuss words. The term "cross compile" was coined at
a time when every machine had only 1 format of executables that it could
execute. Now there are two possible meanings of the term.
> I think a warning is warranted somewhe
t a good idea to assume that you can run all programs just
> because you can run a very simple one
Sure it is possible to write non-portable code and non-portable unit tests.
But this is irrelevant to a discussion about --build and --host.
2012-04-23 Bruno Haible
doc: Mention an effe
Peter Rosin wrote:
> If you don't specify --build when you are cross-compiling (i.e. host !=
> build),
> in an environment where the build system -- for one reason or another -- is
> able
> to execute the host code, the heuristic to detect a cross-compiler fails.
I have never observed this. What
bi-arch compilations in the last 10 years,
all with --host and without --build, and have never observed a problem
with it, except for the warning. Simply relying on config.guess is sufficient.
Therefore I suggest to remove the warning:
2012-04-22 Bruno Haible
AC_INIT: Remove a transiti
Paul Eggert wrote:
> I grew up with "I'm hungry" rather than 'I'm hungry'
Me too (in English).
Personally I use single-quoting (apostrophes) when quoting identifiers,
like @code{} in TeXinfo:
'struct tm'
The 'sentinel' attribute was added in gcc 4.0.
and double-quoting when quoting parts of E
ic cross compilation guess, too?
Autoconf has traditionally used a pessimistic approach to cross compilation
guesses. If the AC_FUNC_STRNLEN macro in Autoconf was to use a more precise
cross compilation guess, there would indeed be no need to duplicate this code
in gnulib. Here i
(already marked obsolescent)
- AC_FUNC_MKTIME
- AC_FUNC_STAT, AC_FUNC_LSTAT (already marked obsolescent)
- AC_FUNC_STRTOD
- AC_REPLACE_FNMATCH (already marked obsolescent)
Removing those that are already marked obsolescent, the following remain:
- AC_FUNC_E
Hi Ralf,
> With the very expressions you are using, you are getting lucky to not
> hit the bug. If you just add a space before $ac_dir, then all of a
> sudden Solaris sh and ksh and other old shells fall apart quickly:
>
> $ ac_dir=./foo
> $ ac_dir_suffix="/`echo " $ac_dir"|sed 's%^\./%%'`"
> ks
Hi Ralf,
> For
> +example, the @command{sed} programs on Solaris 10, HP-UX 11, and AIX
> +don't allow splitting in this case:
> ...
> +In practice, however, it is portable to pass fragments to separate
> +...@option{-e} options that each represent full @command{sed} commands,
> +even if that is
ached the two proposed patches (the first one unchanged, the second one
taking into account your remarks).
From 12fc22759ba2a1dc5f22a938a639913a554297cc Mon Sep 17 00:00:00 2001
From: Bruno Haible
Date: Sat, 19 Jun 2010 00:06:37 +0200
Subject: [PATCH 1/2] Document how to write comments in makefile rule
s a patch to do this, together with an (unrelated, separate) patch
to document how to write comments in Makefile rules.
Does this submission format work? (I don't know whether git-merge-changelog
is active when you do "git am".) If not, please use "patch -p1".
From 12fc22759ba2a
;.
Proposed patch, to be applied with "patch -p0".
2009-12-31 Bruno Haible
Improve documentation on Solaris tr bugs.
* doc/autoconf.texi (Limitations of Usual Tools) : Refine
description of NUL handling by Solaris tr.
*** doc/autoconf.texi.orig Thu Dec 3
Hi Ralf,
> > * doc/autoconf.texi (Debugging): Recommend to use
> > "bash -x -n configure".
>
> Thanks, I completely forgot about -n. What does -x help in conjuction
> with -n though?
A quick test showed me that with current bash, the '-x' is redundant here.
But I've been using "bash -x
Ralf Wildenhues wrote:
> +Makefiles generated by @command{automake} expand @code{$(AM_MAKEFLAGS)}
> +on the command line of submakes, which can be used for propagated overrides
> +(@pxref{Subdirectories, , Automake, automake, @acronym{GNU} Automake}).
Can you add an example for it? Suppose I want
The macros in section "Particular functions" appear to be alphabetically
but not really. Here is a proposed fix:
2009-10-04 Bruno Haible
* doc/autoconf.texi (Particular Functions): Swap sections about
AC_FUNC_MBRTOWC and AC_FUNC_MEMCMP.
*** doc/autoconf.texi.orig
.
Note also that the cache variable for AC_PROG_SED is ac_cv_path_SED, not
ac_cv_prog_SED. And ac_cv_func_getmntent is used as a result variable of
AC_FUNC_GETMNTENT, not as a cache variable name.
2009-10-04 Bruno Haible
* doc/autoconf.texi (AC_PROG_AWK, AC_PROG_GREP, AC_PROG_EGREP,
}
parameters" works only for boolean result variables, and requires the
user to be familiar with functional programming style.
2009-10-04 Bruno Haible
* doc/autoconf.texi (Debugging): Recommend to use
"bash -x -n configure". Recommend the use of result variables as
> - Set up an secondary message file descriptor, initially pointing to
> the same destination as AS_MESSAGE_FD.
Oops, the secondary message file descriptor would have to initially point
to /dev/null. Only AC_MSG_CHECKING would redirect it to the same destination
as AS_MESSAGE_FD.
Burno
Eric Blake wrote:
> Bruno, since you raised the original issue, what do you think of this
> counterproposal?
I agree now that a shell-based solution is better than something based on
pushdef/popdef. For instance, gnulib's lib-ld.m4 has a construct like this:
if ...; then
AC_MSG_CHECKING([fo
Eric Blake wrote:
> Here's what I'm committing as a first round of documentation.
The clarifications about macros with arguments are indisputable; thanks.
Regarding the AC_REQUIRE "bug", you write:
> If you ever
> pass a particular macro name to @code{AC_REQUIRE}, then you are implying
> that th
Eric Blake asked:
> How likely is it that -arch appears multiple times, but always with the
> same argument?
10% to 30%, I'd say. You also often see build command lines with duplicated
-Wall. Why? Because
- some people specify the same flags through both CC and CFLAGS,
- with multiple layers o
ny more) only if there are at least two -arch options with different
values:
$ gcc -arch i386 foo.c -E
# 1 "foo.c"
# 1 ""
# 1 ""
# 1 "foo.c"
$ gcc -arch i386 -arch i386 foo.c -E
# 1 "foo.c"
# 1 ""
# 1 ""
# 1 "foo.c&qu
ilds will be treated as universal! Likewise for -L options in LDFLAGS.
Argh.
Here is a proposed fix:
2008-12-25 Bruno Haible
* lib/autoconf/c.m4 (AC_C_BIGENDIAN): Make detection of options
indicating a universal build more reliable.
*** lib/autoconf/c.m4.orig 2008-12-2
Eric,
> Do you have commit rights, or do you need me to push this?
A committer needs to do this for me, please.
Bruno
not working. Here is a suggestion for telling the users of
GNU software on this OS.
[1] http://lists.gnu.org/archive/html/bug-gnulib/2008-11/msg00285.html
2008-12-22 Bruno Haible
* doc/install.texi (Particular Systems): Add a recommendation which
prefix to use on Haiku
Eric Blake wrote:
> this would be
> better written as a compile-time test that sees whether mbstate_t is
> visible first without, then with -D_XOPEN_SOURCE=500 added to CFLAGS, in
> case HP (or gcc fixincludes) fixes the problem, or in case someone else
> has a similar issue.
This has the potentia
For the C mode, do you
want it in AC_PROG_CC_C89 or AC_PROG_CC_C99 ?
Bruno
2008-12-20 Bruno Haible
Ensure mbstate_t is defined on HP-UX 11.11 when AC_USE_SYSTEM_EXTENSIONS
is used.
* lib/autoconf/specific.m4 (AC_USE_SYSTEM_EXTENSIONS): Require
AC_CANONICAL_HOST. On H
Hi Eric,
> > On HP-UX 11.11, mbstate_t is not defined by unless _XOPEN_SOURCE
> > is
> > set to 500. (Even when _HPUX_SOURCE is set!)
>
> What happens if _XOPEN_SOURCE is set to something larger than 500,
> implying a newer standards version?
Then it is as if the flag was not present at all. O
nk autoconf should recommend to set, and itself default to
setting, -D_XOPEN_SOURCE=500. But *only* on HP-UX! The header files of glibc,
MacOS X, FreeBSD, OpenBSD, NetBSD, AIX, IRIX, OSF/1, Solaris, Cygwin, Haiku,
Interix are also sensitive to the _XOPEN_SOURCE flag.
Here is a proposed p
Ralf Wildenhues wrote:
> > +On HP-UX, the default C compiler is not ANSI C compatible. If GNU CC is
>
> s/GNU CC/GCC/? Wondering because GCC is used elsewhere in the document.
In my understanding, GCC designates the GNU compiler collection (= all of
gcc, g++, gcj, g77), whereas here I mean the
Eric Blake wrote:
> Is this workaround worth documenting, as a way to avoid the ASCII
> dependency on \015?
Probably not now. I'm being over-cautious in gnulib, but I will not apply
this workaround to gettext now. Let's wait and see whether some people report
it as a bug in gettext.
Bruno
Ping? What about installing the patch in
http://lists.gnu.org/archive/html/autoconf-patches/2008-04/msg00050.html ?
The part about HP-UX (-Ae option) could be dropped if
1) AC_USE_SYSTEM_EXTENSIONS is modified to add -Ae.
and
2) AC_PROG_CC_STDC is modified to reject K&R C compilers.
Status
Ralf Wildenhues wrote:
> > I can agree to dropping the recommendation to try CC="cc -Ae" if
> Is there an "or" or an "and" connecting (1) and (2)?
That was an implicit "and" :-)
Let me separate the two issues:
-
1) AC_US
Ralf Wildenhues wrote:
> the bit of qualm I have going this route is that we may
> end up with dozens of recommendations, that all apply to some
> more or less large subset of packages that use Autoconf. For
> the rest it's just bloat.
I don't see the risk of that: 12 years ago, indeed, one neede
uot;we"?
"you should use ..." - sounds too imperative.
> "don't grok" is better written as "cannot parse".
Yes, thanks.
Updated patch is attached.
> Do you need someone to apply it for you?
Yes; I don't have write access to autoconf.
and wording :-)
If there are none, here is the proposed patch:
2008-04-12 Bruno Haible <[EMAIL PROTECTED]>
* doc/install.texi (Particular Systems): New section.
*** install.texi.bak2008-03-14 01:46:05.0 +0100
--- install.texi2008-04-12 19:44:
Ralf Wildenhues wrote:
> I deliberately left out checking all the
> cat >$CONFIG_STATUS <<...
>
> for now, my (weak) rationale being that with a write error, the
> config.status file will likely be completely unusable anyway (and my
> other one being laziness for now). Do you think each one of
Paul Eggert wrote:
> I installed this into Autoconf:
>
> 2007-11-13 Paul Eggert <[EMAIL PROTECTED]>
> ...
> * lib/autoconf/types.m4 (_AC_TYPE_LONG_LONG_SNIPPET):
> Do not check for preprocessor flows.
'flows'? 'flaws'!
Also, I would prefer to not let autoconf/lib/autoconf/types.m4
Paul Eggert wrote:
> > 2007-10-26 Bruno Haible <[EMAIL PROTECTED]>
> >
> > * lib/autoconf/types.m4 (_AC_TYPE_LONG_LONG_SNIPPET): New macro,
> > extracted from AC_TYPE_LONG_LONG_INT and AC_TYPE_UNSIGNED_LONG_LONG_INT.
> > (AC_TYPE_LONG_LONG_INT, AC_
Hi Paul,
On Wednesday, I proposed a patch to disable both 'unsigned long long int'
and 'long long int' on Sun C 5.[0-8] in 32-bit mode, instead of only one
of them.
> 2007-10-24 Bruno Haible <[EMAIL PROTECTED]>
>
> * m4/longlong.m4 (_AC_TYPE_LONG_
Paul Eggert wrote:
> Bruno Haible <[EMAIL PROTECTED]> writes:
>
> > #if ! (-2147483648LL < 0)
> > ...
> > #if ! (-9223372036854775807LL < 0)
>
> If a compiler can't handle that sort of line, then its bugs are more
> serious, since it's
Paul Eggert wrote:
> > 2007-10-22 Bruno Haible <[EMAIL PROTECTED]>
> >
> > * m4/ulonglong.m4 (AC_TYPE_UNSIGNED_LONG_LONG_INT): Use -1ull, not
> > -1u, in preprocessor expression.
>
> Thanks for checking that. I installed that fix into gnulib,
u. Whereas the
one with -1ull works.
Quite explainable:
18446744073709551615ULL is 0xULL
-1u is 0xU
so you end up comparing
0xFFFFFFFFULL against 0xULL
therefore I find it quite natural that this test fails.
Hi Paul,
Paul Eggert wrote on 2007-10-16:
> Thanks for verifying this. I have started by installing the following
> fix to Autoconf, and will follow up on gnulib shortly.
>
> 2007-10-16 Paul Eggert <[EMAIL PROTECTED]>
>
> Check for 64-bit int errors in HP-UX 10.20 preprocessor.
It exis
Steven G. Johnson wrote:
> PPS. In my original macro, I also allowed the user to override the
> OPENMP_*FLAGS via an environment variable. You didn't do this in the
> autoconf version, but it might be a good idea in case a future compiler
> needs some other flag.
The usual way to handle new co
Paul Eggert wrote:
> In reference to:
>
> http://lists.gnu.org/archive/html/autoconf-patches/2007-10/msg00017.html
>
> Bruno contributed that patch to Autoconf, dated 2007-05-21.
> Bruno, was that patch derived from Steven's work?
It was derived from these two comment lines found in Steven's mac
+ break
> done
>fi
>])
Excellent observation. You must be a mathematician :-)
Well, your patch never got to trying the second, third, etc. possibility,
due to the unconditional 'break'. I have tested the appended modified patch:
it works with gcc
Paul Eggert wrote:
> I installed that, after tweaking the documentation a
> bit. Here's the documentation I installed:
Thanks!
> If the current language is C, the macro @code{AC_C_OPENMP} sets the
That should be @code{AC_OPENMP}
Someone knowledgeable with autoconf could revisit the following
not a big problems: Such mistakes will become apparent immediately,
because no compiler I know of has OpenMP support enabled by default.
> make check TESTSUITEFLAGS='-k AC_C_OPENMP -v -d -x'
This fails, apparently because the variables OPENMP_CFLAGS and enable_openmp
(which you told me
Find attached an updated patch, taking into account your remark and one of
Ralf's remarks.
Bruno
2007-05-17 Bruno Haible <[EMAIL PROTECTED]>
* lib/autoconf/c.m4 (AC_C_OPENMP): New macro.
* doc/autoconf.texi (C Compiler): Document AC_C_OPENMP.
* NE
Paul Eggert asked:
> What are the consequences of compiling with -fopenmp etc.?
At compile time, the compiler understands some #pragmas and provides a
header file . At link time, a special library is linked in
(libgomp.so in the case of gcc, libmtsk.so in the case of SunPRO C etc.).
> Can you lin
In the doc, I'm not sure whether one should write "The
> > @code{AC_C_OPENMP} macro" or "The macro @code{AC_C_OPENMP}". Please
> > correct if needed.
>
> FWIW, I'd slightly prefer the latter.
OK.
> > 2007-05-17 Bruno Haible <[EMA
known to be likely to support it.
In the doc, I'm not sure whether one should write "The @code{AC_C_OPENMP} macro"
or "The macro @code{AC_C_OPENMP}". Please correct if needed.
2007-05-17 Bruno Haible <[EMAIL PROTECTED]>
* lib/autoconf/c.m4 (AC_C_O
Paul Eggert wrote:
> +Large outputs may cause trouble. On Solaris 8 through 10, for example,
> +the command @samp{/bin/printf %01x 123} dumps core.
This holds also for Solaris 2.5.1 to Solaris 10.
> This particular
> +bug should have little practical effect since Solaris shells' builtin
> [E
Richard Kenner wrote:
> (3) How many programs are known to rely on wrap semantics? For each:
> (a) How hard was it to determine there was a problem with that
> assumption?
A piece of data for GNU clisp and cln:
- For clisp, it was easy to find out and fix all problems, because the
I'm proposing a patch for automake to support this macro. It requires a
tiny change in autom4te.
2006-10-01 Bruno Haible <[EMAIL PROTECTED]>
* lib/autom4te.in (Automake-preselections): Add
AM_GNU_GETTEXT_INTL_SUBDIR, for automake 1.10.
*** autoconf-2.60a/lib/autom4te.in.ba
: `intl' should not be in SUBDIRS when
AM_GNU_GETTEXT([external]) is used
Here is a patch for automake to support this macro. Quite trivial.
It requires a tiny change in autom4te, which I'm sending to the autoconf
list separately.
2006-10-01 Bruno Haible <[EMAIL PROTECTED]>
Ralf Wildenhues wrote:
> Bruno, please apply this change to fix some M4 underquoting;
Thanks, applied in the gettext CVS.
> I notice this file is similar but not identical to Gnulib's regex.m4 --
> maybe there is a chance to reconcile the differences?
Sometime after the gettext-0.15 release, sur
86 matches
Mail list logo
