> >> 2008-10-23 Simon Josefsson <[EMAIL PROTECTED]>
> >> Bruno Haible <[EMAIL PROTECTED]>
> >>
> >>* lib/stdlib.in.h (@GNULIB_RANDOM_R@): Include stdint.h.
> >>* modules/random_r (Depends-on): Add stdint.
>
> Looks fine. You're welcome to push it.
Applied.
Bruno
Karl,
> I don't know of any reason for any package to use FDL 1.1. I am
> surprised to see it. But as I recall, Bruno did this part, so we
> should wait to hear from him.
The honour goes back to you: the copyright declaration in gnulib.texi
dates back to the first version of this manual that yo
The manual contains a copy of GFDLv1.2 but claims to use v1.1, which
seems inconsistent. Is there a reason not to use v1.2?
I don't know of any reason for any package to use FDL 1.1. I am
surprised to see it. But as I recall, Bruno did this part, so we
should wait to hear from him.
B
On Fri, Oct 24, 2008 at 02:23:03AM +0200, Bruno Haible wrote:
> But in this case, there is a cheap workaround that I can apply even without
> testing.
That indeed fixes the problem, reports Aleksey.
Thanks!
Thomas
Ralf Wildenhues wrote:
> a suggestion for a new name: AC_EVAL_IFELSE.
There's actually two cases to consider, if you want to make it easy to use
for the developer:
- the case of a command that should be executed and logged,
- the case of a variable that contains a command that should be execut
On 2008-10-04 I wrote:
> We are still waiting on Paul's ok for the modules 'strerror' and 'intprops'.
We've got Paul's approval today. I'm applying this:
2008-10-24 Bruno Haible <[EMAIL PROTECTED]>
* modules/intprops (License): Change to LGPLv2+, with approval by Paul
Eggert.
* Eric Blake wrote on Fri, Oct 24, 2008 at 04:15:34AM CEST:
> According to Bruno Haible on 10/23/2008 5:09 PM:
> > There is a need for autoconf macros to compile and execute programs that
> > they have created with AC_LANG_CONFTEST
> > 1) without having to build up the compile or link command by
Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>> strerror.c appears to need intprops only for its
>> definition of the INT_STRLEN_BOUND macro, used here:
>>
>> {
>> char *result = strerror (n);
>>
>> if (result == NULL || result[0] == '\0')
>> {
>> static char const fmt[] = "Unkn
> strerror.c appears to need intprops only for its
> definition of the INT_STRLEN_BOUND macro, used here:
>
> {
> char *result = strerror (n);
>
> if (result == NULL || result[0] == '\0')
> {
> static char const fmt[] = "Unknown error (%d)";
> static char mesg[siz
FYI, I've just pushed this:
Without it, I'd get link errors on mingw about
send_used_without_requesting_gnulib_module_send,
even when using that module.
diff --git a/ChangeLog b/ChangeLog
index b59412e..0bf0c00 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2008-10-24 Jim Meyering <[EMA
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> Using the perror module results in warnings:
>
> warning: module perror depends on a module with an incompatible license:
> intprops
> warning: module perror depends on a module with an incompatible license:
> strerror
>
> The reason appears to be beca
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> Bruno Haible <[EMAIL PROTECTED]> writes:
>
>> If you put a #include inside an extern "C" { ... } block, like this, it
>> yields
>> a syntax error in C++ mode on some platforms. Better put the #include
>> before the extern "C" block, like this:
>
> I lik
Eric Blake <[EMAIL PROTECTED]> wrote:
> According to Jim Meyering on 10/22/2008 9:32 AM:
>> To autoconf folks, I've attached the obvious patch below,
>> and will push it some time tomorrow if no one objects.
>>
>> * lib/autoconf/functions.m4 (AC_FUNC_GETGROUPS): Always define
>> the shell variable,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 10/22/2008 9:32 AM:
> To autoconf folks, I've attached the obvious patch below,
> and will push it some time tomorrow if no one objects.
>
> * lib/autoconf/functions.m4 (AC_FUNC_GETGROUPS): Always define
> the shell variab
Simon Josefsson wrote:
> Do you know which platforms are affected in this way?
At least glibc systems. with g++ versions from 3.3 to 4.2.
$ cat foo.cc
extern "C" {
#include
}
$ g++ -c foo.cc
...
/usr/include/g++/bits/cpp_type_traits.h:71: error: template with C linkage
/usr/include/g++/bits/cpp_
Eric Blake wrote:
> Yes, but it probably should not be named AC_TRY_EVAL ...
> Better than documenting variables would be designing a nicer macro
> interface that exposes what those variables are trying to get at. Every
> time we document a shell variable instead of an autoconf macro, we've
> lock
The manual contains a copy of GFDLv1.2 but claims to use v1.1, which
seems inconsistent. Is there a reason not to use v1.2? The reason for
the non-version number related changes is because I used the template
suggested by GFDLv1.2.
/Simon
diff --git a/doc/gnulib-intro.texi b/doc/gnulib-intro.te
Bruno Haible <[EMAIL PROTECTED]> writes:
> If you put a #include inside an extern "C" { ... } block, like this, it yields
> a syntax error in C++ mode on some platforms. Better put the #include
> before the extern "C" block, like this:
I like the patch better. Jim?
/Simon
>
> 2008-10-23 Simon
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Hi Simon,
>
>> Using the obstack module results in warnings:
>>
>> warning: module obstack depends on a module with an incompatible license:
>> exit
>> warning: module obstack depends on a module with an incompatible license:
>> exitfail
>>
>> The reason
Bruno Haible <[EMAIL PROTECTED]> writes:
> If you put a #include inside an extern "C" { ... } block, like this, it yields
> a syntax error in C++ mode on some platforms. Better put the #include
> before the extern "C" block, like this:
Ah, that's useful information to document somewhere. I pushe
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> Using the freadseek module results in a warning:
>>
>> warning: module freadseek depends on a module with an incompatible license:
>> freadahead
>>
>> The reason appears to be because freadahead is 'LGPL' while freadahead
>> i
21 matches
Mail list logo
