According to the autoconf info files
this might cause problems on some old platforms.
As far as I know, that's incorrect information promulgated originally by
Greg what's-his-name, many years ago. It's come up many times since and
no one has ever come up with an actual platform on which i
On Wed, 2005-05-18 at 12:51 -0700, Paul Eggert wrote:
> Yoann Vandoorselaere <[EMAIL PROTECTED]> writes:
>
> > There is also a problem with the 'intprops.h' dependency.
> > When gnulib-tool is run, the file is included, but it doesn't seem to be
> > listed as part of the generated Makefile.am, le
Yoann Vandoorselaere <[EMAIL PROTECTED]> writes:
> There is also a problem with the 'intprops.h' dependency.
> When gnulib-tool is run, the file is included, but it doesn't seem to be
> listed as part of the generated Makefile.am, leading to 'dist' trouble.
I have removed this dependency; fts no
I installed this into gnulib. This is just an internal cleanup; it
shouldn't affect behavior.
2005-05-18 Paul Eggert <[EMAIL PROTECTED]>
* lib/canonicalize.c: Include canonicalize.h first, to test interface.
Include unconditionally, since we assume C89 now.
All uses of
The latest patch looks reasonable to me. Bruno, you're the minmax
maintainer: can you please take a look at it?
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Paul Eggert wrote:
>Derek Price <[EMAIL PROTECTED]> writes:
>
>
>
>>Corrected patch attached.
>>
>>
>
>Thanks. A couple more things. (Sorry I didn't catch it earlier.)
>First, the $gl_* variables should be cached, with AC_CACHE_CHECK.
>
>
Done.
>Second, suppose and have conflicting
>
On Wed, 2005-05-18 at 16:16 +0100, Ian Abbott wrote:
> On 17/05/2005 10:20, Yoann Vandoorselaere wrote:
> > However, I still consider this version of the patch to be a hack, when
> > the real bug here is that you should not use const since you permit the
> > user to free() the data from the interfa
Yoann Vandoorselaere <[EMAIL PROTECTED]> wrote:
...
> There is also a problem with the 'intprops.h' dependency.
> When gnulib-tool is run, the file is included, but it doesn't seem to be
> listed as part of the generated Makefile.am, leading to 'dist' trouble.
Thanks. I've fixed it:
2005-05-18
Derek Price <[EMAIL PROTECTED]> writes:
> +# define GETPW_R_SIZE_MAX() (-1);
There shouldn't be a semicolon here.
>>># ifndef __USE_GNU
>>># define __USE_GNU 1
>>># endif
>>
>>This shouldn't be needed once the change is needed,
>>because should define __USE_GNU.
>
> No, because we want _
Derek Price <[EMAIL PROTECTED]> writes:
> Corrected patch attached.
Thanks. A couple more things. (Sorry I didn't catch it earlier.)
First, the $gl_* variables should be cached, with AC_CACHE_CHECK.
Second, suppose and have conflicting
definitions of MIN and MAX? To work around the latter po
On Tue, 2005-05-17 at 12:25 +0200, Jim Meyering wrote:
> Yoann Vandoorselaere <[EMAIL PROTECTED]> wrote:
> > Another things is that including the fts module trigger a missing
> > dependency:
> > ../src/.libs/libprelude.so: undefined reference to `xalloc_die'
>
> That's because the hash module uses
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Eggert wrote:
>Answering my own question: yes it will, in general, because perhaps
>the gnulib version fixes a bug that's in the glibc version, and the
>user wants the gnulib version. So we should worry about this.
>And (as far as I can see) the
On 17/05/2005 10:20, Yoann Vandoorselaere wrote:
However, I still consider this version of the patch to be a hack, when
the real bug here is that you should not use const since you permit the
user to free() the data from the interface callback. The interface
should not use const at all.
Can you sho
Derek Price <[EMAIL PROTECTED]> writes:
> # ifndef __USE_GNU
> # define __USE_GNU 1
> # endif
This shouldn't be needed once the change is needed,
because should define __USE_GNU.
> +# define GETPW_R_SIZE_MAX() -1;
Change "-1;" to "(-1)".
> -#endif /* GLOB_ONLY_P */
> +#endif /* !_LIBC
Derek Price <[EMAIL PROTECTED]> writes:
>>But let's step back a second. Why are we worried about building
>>gnulib glob.c under glibc? It will never happen, right? So perhaps
>>we needn't worry about this problem at all.
>
> Won't it? I thought the idea was that when you and I settled on
> someth
The following script files in the gnulib library have `#!/...' instead
of `#! /...' in the first line. According to the autoconf info files
this might cause problems on some old platforms. Today this is
probably no longer important, but I think it is a good idea to make
all shebangs in the vario
16 matches
Mail list logo
