Derek Price <[EMAIL PROTECTED]> writes:
> After that I will write up a ChangeLog entry for the glob-glibc2gnulib
> diff and submit our changes back to the glibc team, unless someone here
> who is used to working with them would like to take a go at the actual
> submission part. Perhaps it would b
Paul Eggert writes:
>
> I should warn you that the C Standard does not allow that sort of
> cast. This is for portability to hosts that use different
> representations for different kinds of pointers; such hosts can use
> different calling conventions for char * and void *, so casting the
> funct
When I ran gettextize to update the hello sources to gettext 0.14.5, it
added build-aux/mkinstalldirs to the top-level EXTRA_DIST.
mkinstalldirs was not an included file in the gnulib gettext module
(I'd previously run gnulib-tool --import). So it seems either it
should be added in gnulib, or r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Conrad T. Pino wrote:
>breaks the Windows build since Microsoft does NOT provide "sys/cdefs.h"
>implementation.
Yes. Since we don't run configure on Windows, _SYS_CDEFS_H needed to be
defined to 1 in the windows-NT/config.h.in.in. I've done so and
Hi Derek,
> From: Derek Price
>
> Done. I added this comment to both glob_.h & glob.m4, with different
> comment leaders, of course:
>
> /* Note the reversal of the common HAVE_SYS_CDEFS_H idiom below. In this
>way, #ifndef _SYS_CDEFS_H may be used to include both when
>it has been ch
Paul Eggert wrote:
>Derek Price <[EMAIL PROTECTED]> writes:
>
>
>
>>Fair enough, but why undo the change to glob.m4? Shouldn't I just
>>change the target of the AC_DEFINE from MISSING_SYS_CDEFS_H to _SYS_CDEFS_H?
>>
>>
>
>Yes, you're right.
>
>Sorry, I'd forgotten the trick that I had sugge
Derek Price <[EMAIL PROTECTED]> writes:
> Fair enough, but why undo the change to glob.m4? Shouldn't I just
> change the target of the AC_DEFINE from MISSING_SYS_CDEFS_H to _SYS_CDEFS_H?
Yes, you're right.
Sorry, I'd forgotten the trick that I had suggested. (This suggests
that it deserves a n
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Also, while we're on the subject of lstat, what operating systems
> have the bug caught by AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK?
> If they are sufficiently old, perhaps we can simply remove
> the lstat module as well. That would be nice.
It's going to be
