Hi Sam, Bruno,
On 12 Oct 2010, at 08:39, Gary V. Vaughan wrote:
> On 12 Oct 2010, at 06:17, Bruno Haible wrote:
You probably renamed the inclusion guard (_GL_STDLIB_H)
appropriate (as recommended).
>>>
>>> does this "as recommended" mean that you are now more amenable to
>>> accepting m
On 10/11/10 20:18, Gary V. Vaughan wrote:
> Then I believe the only viable option to provide stable support
> for multiple gnulib directories in a single tree is to add a
> switch to gnulib-tool to rewrite gnulib #include_next lines
> on import, so that both types of compilers include header
> file
Hi Eric,
On 12 Oct 2010, at 08:54, Eric Blake wrote:
> On 10/11/2010 07:39 PM, Gary V. Vaughan wrote:
>> There are only two options to make both cases behave the same -
>>
>> 1. always hardcode the full path to the system header, even on machines
>> with include_next support;
>
> (1) is n
On 10/11/2010 07:39 PM, Gary V. Vaughan wrote:
There are only two options to make both cases behave the same -
1. always hardcode the full path to the system header, even on machines
with include_next support;
(1) is not viable. If a system header itself uses include_next, then we
M
Hi Sam, Bruno,
On 12 Oct 2010, at 06:17, Bruno Haible wrote:
>>> You probably renamed the inclusion guard (_GL_STDLIB_H)
>>> appropriate (as recommended).
>>
>> does this "as recommended" mean that you are now more amenable to
>> accepting my patch?
>> http://clisp.cvs.sourceforge.net/viewvc/clis
Hi Paul,
On 12 Oct 2010, at 00:12, Paul Eggert wrote:
> On 10/11/10 05:28, Gary V. Vaughan wrote:
>
>> Ping?
>
> I just now looked at it, and my goodness, there are a lot of changes.
> I don't get the big picture: why are the changes being made? Perhaps
> you could briefly discuss that?
Thanks
Hi Eric,
On 12 Oct 2010, at 03:24, Eric Blake wrote:
> On 10/08/2010 10:15 PM, Gary V. Vaughan wrote:
>> Please find attached: bootstrap itself, and matching bootstrap.conf
>> files for m4, libtool and coreutils resp. (using master as at 2 weeks
>> ago or thereabouts).
>
> Rather than one giant c
Hi Sam,
> > You probably renamed the inclusion guard (_GL_STDLIB_H)
> > appropriate (as recommended).
>
> does this "as recommended" mean that you are now more amenable to
> accepting my patch?
> http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/gnulib-tool.patch?view=log
The fact that you hav
Hi Sam,
> some platforms have malloc implementations with extra features like
> randomizations, and some applications cannot handle those features.
> thus emacs (and clisp) come with gmalloc.c by Mike Haertel.
> It would be nice if it were offered by gnulib
Generally one should use the malloc()
Hi Bruno,
On Mon, Oct 11, 2010 at 6:41 PM, Bruno Haible wrote:
>
> It sounds like you have two invocations for gnulib-tool, one for gllib,
> and one for regexp/gllib.
you must be clairvoyant.
> You probably renamed the inclusion guard (_GL_STDLIB_H)
> appropriate (as recommended).
does this "a
Hi Sam,
> I am getting this error
> when compiling gllib in the regexp clisp module on mingw and cygwin:
> gcc -mno-cygwin -DHAVE_CONFIG_H -I. -I/.../current/modules/regexp/gllib -I..
> -I/.../top/include -I/.../current/build-mingw-g-7/gllib
> -I/.../current/build-mingw-g-7 -g -O2 -W -Wswitch
some platforms have malloc implementations with extra features like
randomizations, and some applications cannot handle those features.
thus emacs (and clisp) come with gmalloc.c by Mike Haertel.
It would be nice if it were offered by gnulib, so that I won't have to have my
own special login to
All of a sudden (after the 27-Sep-10 sync with gnulib) I am getting this error
when compiling gllib in the regexp clisp module on mingw and cygwin:
gcc -mno-cygwin -DHAVE_CONFIG_H -I. -I/.../current/modules/regexp/gllib -I..
-I/.../top/include -I/.../current/build-mingw-g-7/gllib
-I/.../current/
Eric Blake wrote:
> Revert "test-futimens: avoid unwarranted test failure on Solaris 5.11"
> This reverts commit 0afab138f4aedb7eaab70957c164aa0e5eb01fce.
>
> * m4/futimens.m4 (gl_FUNC_FUTIMENS): Detect the bug.
> * tests/test-futimens.h (test_futimens): Enhance, rather than
> weaken test.
> * doc/
On 10/08/2010 10:15 PM, Gary V. Vaughan wrote:
Please find attached: bootstrap itself, and matching bootstrap.conf
files for m4, libtool and coreutils resp. (using master as at 2 weeks
ago or thereabouts).
Rather than one giant change for bootstrap, could you post it as a
series of incremental
Revert "test-futimens: avoid unwarranted test failure on Solaris 5.11"
This reverts commit 0afab138f4aedb7eaab70957c164aa0e5eb01fce.
* m4/futimens.m4 (gl_FUNC_FUTIMENS): Detect the bug.
* tests/test-futimens.h (test_futimens): Enhance, rather than
weaken test.
* doc/posix-functions/futimens.texi (
Eric Blake wrote:
> On 10/11/2010 04:51 AM, Jim Meyering wrote:
>> That's because futimens (AT_FDCWD, NULL) would fail with errno set to
>> EFAULT, rather than the expected value of EBADF.
>>
>> At first I was going to relax the test to allow "|| errno == EFAULT",
>> but what if EFAULT is not defin
On 10/11/10 01:05, Gary V. Vaughan wrote:
> Pushed as an obvious fix to rebalance parentheses.
Thanks, and sorry about that. I didn't catch it because coreutils doesn't
use that .h file. I originally messed up the parentheses partly because
the code was using a non-GNU indenting style:
((FO
Hello Gary,
* Gary V. Vaughan wrote on Mon, Oct 11, 2010 at 09:31:55AM CEST:
> On 9 Oct 2010, at 22:40, Bruce Korb wrote:
> >> I think I know why pkg-config makes autotools people wince...
> >>
> >>
> >> I still regret not having noticed pkg-config before it became so pervasive
> >> -
> >> it b
On 10/11/10 05:28, Gary V. Vaughan wrote:
> Ping?
I just now looked at it, and my goodness, there are a lot of changes.
I don't get the big picture: why are the changes being made? Perhaps
you could briefly discuss that?
On 10/10/2010 08:19 PM, Gary V. Vaughan wrote:
The common way to get rid of these warnings is to insert an invocation of
gl_USE_SYSTEM_EXTENSIONS at the appropriate place in configure.ac.
Seems like a kludge to me. Either the AC_{RUN,COMPILE}_IFELSE using modules
should AC_REQUIRE_ONCE([gl_USE
[adding bug-autoconf]
On 10/10/2010 11:02 PM, Gary V. Vaughan wrote:
Hi Bruce,
On 10 Oct 2010, at 22:26, Bruce Korb wrote:
The common way to get rid of these warnings is to insert an invocation of
gl_USE_SYSTEM_EXTENSIONS at the appropriate place in configure.ac.
Could you explicitly define
Hi Bruce,
On 11 Oct 2010, at 22:10, Bruce Korb wrote:
> On Mon, Oct 11, 2010 at 12:31 AM, Gary V. Vaughan wrote:
>> libtool already contains most of the information that pkg-config wants,
>
> Yep. And rather than what would likely be a futile fight to
> migrate from ``pkg-config --cflags libname
Hi Gary,
On Mon, Oct 11, 2010 at 12:31 AM, Gary V. Vaughan wrote:
> It is the .pc files that are the problem actually.
Yes. I understand. It is a nuisance to find them on a system.
> libtool already contains most of the information that pkg-config wants,
Yep. And rather than what would likel
Hi Gary, Ralf,
On Sun, Oct 10, 2010 at 11:34 PM, Gary V. Vaughan wrote:er.
>
> Agreed, with some caveats.
>
> Since this affects many gnulib modules, libposix or not:
>
> --- a/modules/stdlib
> +++ b/modules/stdlib
> @@ -18,6 +18,7 @@ configure.ac:
> gl_STDLIB_H
>
> Makefile.am
> +noinst_HEADERS
On 9 Oct 2010, at 11:15, Gary V. Vaughan wrote:
> Seeing the renewed interest in patching the gnulib bootstrap script,
> and how I won't have time for at least a couple of weeks to finish
> my planned bootstrap.conf rewrite for as many bootstrap using GNU
> projects as I could lay my hands on... no
On 10/11/2010 04:51 AM, Jim Meyering wrote:
That's because futimens (AT_FDCWD, NULL) would fail with errno set to
EFAULT, rather than the expected value of EBADF.
At first I was going to relax the test to allow "|| errno == EFAULT",
but what if EFAULT is not defined? There's only one other use
There was one gnulib test failure (via coreutils) on Solaris 5.11:
FAIL: test-futimens (exit: 262)
===
test-futimens.h:81: assertion failed
That's because futimens (AT_FDCWD, NULL) would fail with errno set to
EFAULT, rather than the expected value of EBADF
Gary V. Vaughan wrote:
> Pushed as an obvious fix to rebalance parentheses.
>
> * lib/spawn.in.h (verify_POSIX_SPAWN_USEVFORK_no_overlap): Fix mismatched
> parens.
> ---
> ChangeLog |6 ++
> lib/spawn.in.h |2 +-
> 2 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/
On 11 Oct 2010, at 15:21, Jim Meyering wrote:
> Gary V. Vaughan wrote:
>>
>> +++ b/ChangeLog
>> @@ -1,3 +1,9 @@
>> +2010-10-11 Gary V. Vaughan
>> +
>> +Fix mismatched parens in previous commit
>> +* lib/spawn.in.h (verify_POSIX_SPAWN_USEVFORK_no_overlap): Fix
>> mismatched
>> +pare
Pushed as an obvious fix to rebalance parentheses.
* lib/spawn.in.h (verify_POSIX_SPAWN_USEVFORK_no_overlap): Fix mismatched
parens.
---
ChangeLog |6 ++
lib/spawn.in.h |2 +-
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 6a56a31..d32d
Hi Bruce,
On 9 Oct 2010, at 22:40, Bruce Korb wrote:
>> I think I know why pkg-config makes autotools people wince...
>>
>>
>> I still regret not having noticed pkg-config before it became so pervasive -
>> it basically repeats all of the work libtool already did, and then ignores
>> a few criti
32 matches
Mail list logo
