Re: Feature Branch Windows Build Broken - lib/canonicalize.c - ELOOP & lstat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Conrad T. Pino wrote: >Hi All, > >The new module "lib/canonicalize.c" fails to compile because it references >the symbolic error "ELOOP" which Windows does not define. > >The new module "lib/canonicalize.c" calls the "lstat" function and there >is no prototype and no implementation on Windows platform we support. > >We use "CVS_LSTAT" macro in the "src" directory which maps to "wnt_lstat" >which we implement in "windows-NT/filesubr.c". We also have "lib/stat.c" >module. I've just checked in a patch which replaces all references to "CVS_STAT" with "stat" and all references to "CVS_LSTAT" with "lstat". I've made changes to the GNULIB modules to support this and submitted the changes back to GNULIB. I also checked them into CVS to speed up our resolution of this issue. >Currently the Windows build doesn't use the "lib/stat.c" module. I think it shouldn't. the GNULIB stat and lstat modules replace stat and lstat when some specific UNIX bugs are encountered, but rely on the underlying stat & lstat to work. The simplest thing to do at this point would probably just be to #define stat wnt_stat and #define lstat wnt_lstat in windows-NT/config.h.in.in. If you are feeling particularly motivated to ramp up the Windows support in GNULIB, you could try to package the work wnt_stat and wnt_lstat do on Windows into the GNULIB stat module and submit the whole back to bug-gnulib@gnu.org, but it shouldn't be necessary and there has been serious resistance there to adding anything to GNULIB modules like the GetUTCFileModTime Windows system call that check_statbuf appears to be making. >The questions raised appear to be: > >1. Where should an "ELOOP" definition be placed? > >2. How should the "ELOOP" value be selected? These are good questions. Is there any similar errno macro on Windows to ELOOP? ELOOP happens on UNIX when a program encounters symbolic links like this: ln -s dir2 dir1(dir1 --> dir2) ln -s dir1 dir2(dir2 --> dir1) and then a function is asked to evaluate a path containing one of these elements, like `./dir1/sdir/file'. Is something similar possible with Windows links? If so, there should be a "correct" substitute for ELOOP on Windows. >An incomplete patch set to the Windows build files is below to allow the >Visual Studio IDE build to complete up to the EXE link. I plan to commit >a complete fix once a consensus on the above issues emerges. The ELOOP definition in your patch may not be the best, but your build file changes should be fine. Cheers, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCk5i/LD1OTBfyMaQRAmpzAKCtKaFhT+SCkBBAyBiZqVdDMh8oqACgngpx VyNsMm+TNZhbrpY6s6CKUs8= =BD3e -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: Feature Branch Windows Build Broken - lib/canonicalize.c - ELOOP & lstat
Hi Derek,
> From: Derek Price
>
> I've just checked in a patch which replaces all references to "CVS_STAT"
> with "stat" and all references to "CVS_LSTAT" with "lstat". I've made
> changes to the GNULIB modules to support this and submitted the changes
> back to GNULIB. I also checked them into CVS to speed up our resolution
> of this issue.
I'm sorry to see CVS_STAT and CVS_LSTAT go. They provided an abstraction
that made CVS less platform bound. The change makes us consistent with
GNU Lib which wouldn't be a problem if they were open to Windows native
API calls in GNU Lib code.
> >Currently the Windows build doesn't use the "lib/stat.c" module.
>
> I think it shouldn't. the GNULIB stat and lstat modules replace stat
> and lstat when some specific UNIX bugs are encountered, but rely on the
> underlying stat & lstat to work. The simplest thing to do at this point
> would probably just be to #define stat wnt_stat and #define lstat
> wnt_lstat in windows-NT/config.h.in.in.
I agree this is simpler given the removal of CVS_STAT and CVS_LSTAT and
GNULIB Windows support state.
> If you are feeling particularly motivated to ramp up the Windows support
> in GNULIB, you could try to package the work wnt_stat and wnt_lstat do
> on Windows into the GNULIB stat module and submit the whole back to
> bug-gnulib@gnu.org, but it shouldn't be necessary and there has been
> serious resistance there to adding anything to GNULIB modules like the
> GetUTCFileModTime Windows system call that check_statbuf appears to be
> making.
I'm willing to take on only what's possible and your opinion counts:
Does GNULIB include the Windows platform in it's charter?
If yes, what's your take on the resistance to Windows native API calls?
> These are good questions. Is there any similar errno macro on Windows
> to ELOOP? ELOOP happens on UNIX when a program encounters symbolic
> links like this:
>
> ln -s dir2 dir1(dir1 --> dir2)
> ln -s dir1 dir2(dir2 --> dir1)
>
> and then a function is asked to evaluate a path containing one of these
> elements, like `./dir1/sdir/file'. Is something similar possible with
> Windows links? If so, there should be a "correct" substitute for ELOOP
> on Windows.
The short answers are "no" and long answers follow:
The Windows "errno.h" file is below.
No Windows file system I'm aware of supports symbolic links. The closest
Windows concepts are the "Shortcut" which is a special binary file with a
"*.lnk" extension and the "reparse point". I can't say how they look to
the native file API.
The Windows NTFS supports hard links which I assume are supported in the
native API since MKS "ln" utility can creates them but their use is rare
since the Windows user interface provides no support to create them.
http://msdn.microsoft.com/library/en-us/fileio/fs/hard_links_and_junctions.asp
Microsoft doesn't support directory hard links.
I'm don't know if reparse point loops are possible.
Since our Windows support is "client" mode only do loops matter?
> Cheers,
Ditto,
> Derek
Conrad
/***
*errno.h - system wide error numbers (set by system calls)
*
* Copyright (c) 1985-1997, Microsoft Corporation. All rights reserved.
*
*Purpose:
* This file defines the system-wide error numbers (set by
* system calls). Conforms to the XENIX standard. Extended
* for compatibility with Uniforum standard.
* [System V]
*
* [Public]
*
/
#if _MSC_VER > 1000
#pragma once
#endif
#ifndef _INC_ERRNO
#define _INC_ERRNO
#if !defined(_WIN32) && !defined(_MAC)
#error ERROR: Only Mac or Win32 targets supported!
#endif
#ifdef __cplusplus
extern "C" {
#endif
/* Define _CRTIMP */
#ifndef _CRTIMP
#ifdef _DLL
#define _CRTIMP __declspec(dllimport)
#else /* ndef _DLL */
#define _CRTIMP
#endif /* _DLL */
#endif /* _CRTIMP */
/* Define __cdecl for non-Microsoft compilers */
#if ( !defined(_MSC_VER) && !defined(__cdecl) )
#define __cdecl
#endif
/* Define _CRTAPI1 (for compatibility with the NT SDK) */
#ifndef _CRTAPI1
#if _MSC_VER >= 800 && _M_IX86 >= 300
#define _CRTAPI1 __cdecl
#else
#define _CRTAPI1
#endif
#endif
/* declare reference to errno */
#if (defined(_MT) || defined(_DLL)) && !defined(_MAC)
_CRTIMP extern int * __cdecl _errno(void);
#define errno (*_errno())
#else /* ndef _MT && ndef _DLL */
_CRTIMP extern int errno;
#endif /* _MT || _DLL */
/* Error Codes */
#define EPERM 1
#define ENOENT 2
#define ESRCH 3
#define EINTR 4
#define EIO 5
#define ENXIO 6
#define E2BIG 7
#define ENOEXEC 8
#define EBADF 9
#define ECHILD 10
#define EAGAIN 11
#define ENOMEM 12
#define EACCES 13
#define EFAULT 14
#define EBUSY 16
#define EEXIST 17
#define EXDEV 18
#define ENODEV 19
#define ENOTDIR 20
#define EISDIR 21
#define EINVAL 22
#define ENFILE
RE: Feature Branch Windows Build Broken - lib/canonicalize.c - ELOOP & lstat
Hi Derek,
Here's a rough draft of a patch that allows Windows build to complete.
The draft includes edited files only and ignores generated files and
Windows build projects files are also omitted.
Briefly the plan is:
#define stat wnt_stat
#define lstat wnt_stat
int wnt_stat (const char *file, struct wnt_stat *sb);
Delete wnt_lstat definition
Prevent "lib/system.h" from redefining "lstat".
Please review and revise the concept and I'll commit the results.
Conrad
Index: lib/system.h
===
RCS file: /cvs/ccvs/lib/system.h,v
retrieving revision 1.76
diff -u -p -r1.76 system.h
--- lib/system.h24 May 2005 21:05:37 - 1.76
+++ lib/system.h25 May 2005 01:20:36 -
@@ -371,7 +371,7 @@ extern int errno;
otherwise return it unchanged. */
#define convert_blocks(b, k) ((k) ? ((b) + 1) / 2 : (b))
-#ifndef S_ISLNK
+#if !defined(lstat) && !defined(S_ISLNK)
# define lstat stat
#endif
Index: windows-NT/config.h.in.footer
===
RCS file: /cvs/ccvs/windows-NT/config.h.in.footer,v
retrieving revision 1.4
diff -u -p -r1.4 config.h.in.footer
--- windows-NT/config.h.in.footer 1 Mar 2005 14:37:39 - 1.4
+++ windows-NT/config.h.in.footer 25 May 2005 01:20:37 -
@@ -11,11 +11,7 @@
#define CVS_MKDIR wnt_mkdir
int wnt_mkdir (const char *PATH, int MODE);
-#define CVS_STAT wnt_stat
-int wnt_stat ();
-
-#define CVS_LSTAT wnt_lstat
-int wnt_lstat ();
+int wnt_stat (const char *file, struct wnt_stat *sb);
#define CVS_RENAME wnt_rename
int wnt_rename (const char *, const char *);
@@ -95,3 +91,6 @@ char *sock_strerror (int errnum);
/* getpagesize is missing on Windows, but 4096 seems to do the right
thing. */
#define getpagesize() 4096
+
+/* Windows has no ELOOP value in errno.h */
+#define ELOOP 1
Index: windows-NT/config.h.in.in
===
RCS file: /cvs/ccvs/windows-NT/config.h.in.in,v
retrieving revision 1.30
diff -u -p -r1.30 config.h.in.in
--- windows-NT/config.h.in.in 2 May 2005 14:08:18 - 1.30
+++ windows-NT/config.h.in.in 25 May 2005 01:20:37 -
@@ -92,8 +92,9 @@
message to be appended to the temp file when the editor is started. */
#undef FORCE_USE_EDITOR
-/* Define if gettimeofday clobbers localtime's static buffer. */
-#undef GETTIMEOFDAY_CLOBBERS_LOCALTIME_BUFFER
+/* Define to rpl_ if the glob replacement functions and variables should be
+ used. */
+#define GLOB_PREFIX rpl_
/* Define to an alternative value if GSS_C_NT_HOSTBASED_SERVICE isn't defined
in the gssapi.h header file. MIT Kerberos 1.2.1 requires this. Only
@@ -1083,6 +1084,9 @@
/* Define to rpl_localtime if the replacement function should be used. */
#undef localtime
+/* Define to a substitute for the `lstat' function. */
+#define lstat wnt_stat
+
/* Define to rpl_malloc if the replacement function should be used. */
#undef malloc
@@ -1132,6 +1136,9 @@
/* Define as a signed type of the same size as size_t. */
#define ssize_t int
+/* Define to a substitute for the stat function. */
+#define stat wnt_stat
+
/* Define to rpl_tzset if the wrapper function should be used. */
#undef tzset
Index: windows-NT/filesubr.c
===
RCS file: /cvs/ccvs/windows-NT/filesubr.c,v
retrieving revision 1.56
diff -u -p -r1.56 filesubr.c
--- windows-NT/filesubr.c 23 May 2005 22:56:16 - 1.56
+++ windows-NT/filesubr.c 25 May 2005 01:20:40 -
@@ -970,26 +970,17 @@ static void check_statbuf (const char *f
error (1, 0, "Failed to retrieve modification time for %s", file);
}
-/* see CVS_STAT */
-int
-wnt_stat (const char *file, struct stat *sb)
-{
-int retval;
+/* undo config.h macros */
+#undef stat
+extern int stat (const char *file, struct wnt_stat *sb);
-retval = stat (file, sb);
-if (retval < 0)
- return retval;
-check_statbuf (file, sb);
-return retval;
-}
-
-/* see CVS_LSTAT */
+/* see stat macro */
int
-wnt_lstat (const char *file, struct stat *sb)
+wnt_stat (const char *file, struct wnt_stat *sb)
{
int retval;
-retval = lstat (file, sb);
+retval = stat (file, sb);
if (retval < 0)
return retval;
check_statbuf (file, sb);
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature Branch Windows Build Broken - lib/canonicalize.c - ELOOP & lstat
Conrad T. Pino wrote: >Hi Derek, > > > >>From: Derek Price >> >>I've just checked in a patch which replaces all references to "CVS_STAT" >>with "stat" and all references to "CVS_LSTAT" with "lstat". I've made >>changes to the GNULIB modules to support this and submitted the changes >>back to GNULIB. I also checked them into CVS to speed up our resolution >>of this issue. >> >> > >I'm sorry to see CVS_STAT and CVS_LSTAT go. They provided an abstraction >that made CVS less platform bound. The change makes us consistent with >GNU Lib which wouldn't be a problem if they were open to Windows native >API calls in GNU Lib code. > > Actually, because of errors similar to the ones you've been seeing on Solaris, it sounds like GNULIB will be defining similar gl_stat and gl_lstat macros. I will either make the canonicalize module use those and depend on the stat module or we can define both stat and gl_stat for the windows port. >>If you are feeling particularly motivated to ramp up the Windows support >>in GNULIB, you could try to package the work wnt_stat and wnt_lstat do >>on Windows into the GNULIB stat module and submit the whole back to >>bug-gnulib@gnu.org, but it shouldn't be necessary and there has been >>serious resistance there to adding anything to GNULIB modules like the >>GetUTCFileModTime Windows system call that check_statbuf appears to be >>making. >> >> > >I'm willing to take on only what's possible and your opinion counts: > >Does GNULIB include the Windows platform in it's charter? > > Sometimes. How are your arm wrestling skills? :) >If yes, what's your take on the resistance to Windows native API calls? > > Windows native API call resistance was pretty strong last time I came up against it, but GNULIB team members were willing to suggest compromises that at least compiled on Windows. >Since our Windows support is "client" mode only do loops matter? > > Yes, to the extent that the Windows client will support a local repository. It may be true that the loops are impossible on Windows since links are not processed in the same way. Regards, Derek ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature Branch Windows Build Broken - lib/canonicalize.c - ELOOP & lstat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Conrad T. Pino wrote: >Hi Derek, > >Here's a rough draft of a patch that allows Windows build to complete. >The draft includes edited files only and ignores generated files and >Windows build projects files are also omitted. > >Briefly the plan is: > > #define stat wnt_stat > #define lstat wnt_stat > > int wnt_stat (const char *file, struct wnt_stat *sb); > > Delete wnt_lstat definition Are stat and lstat really equivalent on Windows? >Index: lib/system.h >=== >RCS file: /cvs/ccvs/lib/system.h,v >retrieving revision 1.76 >diff -u -p -r1.76 system.h >--- lib/system.h 24 May 2005 21:05:37 - 1.76 >+++ lib/system.h 25 May 2005 01:20:36 - >@@ -371,7 +371,7 @@ extern int errno; > otherwise return it unchanged. */ > #define convert_blocks(b, k) ((k) ? ((b) + 1) / 2 : (b)) > >-#ifndef S_ISLNK >+#if !defined(lstat) && !defined(S_ISLNK) > # define lstat stat > #endif I suspect this was only relevant on Windows anyhow and the entire block can be removed. >Index: windows-NT/config.h.in.footer >=== >RCS file: /cvs/ccvs/windows-NT/config.h.in.footer,v >retrieving revision 1.4 >diff -u -p -r1.4 config.h.in.footer >--- windows-NT/config.h.in.footer 1 Mar 2005 14:37:39 - 1.4 >+++ windows-NT/config.h.in.footer 25 May 2005 01:20:37 - >@@ -11,11 +11,7 @@ > #define CVS_MKDIR wnt_mkdir > int wnt_mkdir (const char *PATH, int MODE); > >-#define CVS_STAT wnt_stat >-int wnt_stat (); >- >-#define CVS_LSTAT wnt_lstat >-int wnt_lstat (); >+int wnt_stat (const char *file, struct wnt_stat *sb); This may prove unnecessary. See below. > #define CVS_RENAME wnt_rename > int wnt_rename (const char *, const char *); >@@ -95,3 +91,6 @@ char *sock_strerror (int errnum); > /* getpagesize is missing on Windows, but 4096 seems to do the right > thing. */ > #define getpagesize() 4096 >+ >+/* Windows has no ELOOP value in errno.h */ >+#define ELOOP 1 How about #define ELOOP EMLINK? At least if this error ever comes up, sterror will then produce a somewhat meaningful error message on Windows. >Index: windows-NT/config.h.in.in >=== >RCS file: /cvs/ccvs/windows-NT/config.h.in.in,v >retrieving revision 1.30 >diff -u -p -r1.30 config.h.in.in >--- windows-NT/config.h.in.in 2 May 2005 14:08:18 - 1.30 >+++ windows-NT/config.h.in.in 25 May 2005 01:20:37 - >@@ -92,8 +92,9 @@ > message to be appended to the temp file when the editor is started. */ > #undef FORCE_USE_EDITOR > >-/* Define if gettimeofday clobbers localtime's static buffer. */ >-#undef GETTIMEOFDAY_CLOBBERS_LOCALTIME_BUFFER Why are you removing these lines? Cheers, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFClJehLD1OTBfyMaQRAghmAJ92Y1HxX1mz9Nr5N/vGtEQeu3XORQCfaFP1 5XRVx2RxZSdqN4YiqT1jrsw= =I2jp -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: Feature Branch Windows Build Broken - lib/canonicalize.c - ELOOP & lstat
Hi Derek, > From: Derek Price > > Actually, because of errors similar to the ones you've been seeing on > Solaris, it sounds like GNULIB will be defining similar gl_stat and > gl_lstat macros. I will either make the canonicalize module use those > and depend on the stat module or we can define both stat and gl_stat for > the windows port. The hard part is the "stat" token which is both a function name and a structure name which the macro processor can't distinguish and both are substituted which is the root of the problem we saw on Solaris. It makes the Windows function "wnt_stat" arguments look odd on casual inspection. The preprocessor is a blunt instrument in a language supporting multiple name speaces. Using "typedef struct stat struct_stat;" before the "#define stat ..." helps a lot with this issue. I prefer this since functions and typedefs occupy the same name space. > >Does GNULIB include the Windows platform in it's charter? > > Sometimes. How are your arm wrestling skills? :) I was afraid of that "sometimes" part. I've watched you get into the ring and it's a pretty site only if you're into blood sports. :) > >If yes, what's your take on the resistance to Windows native API calls? > > Windows native API call resistance was pretty strong last time I came up > against it, but GNULIB team members were willing to suggest compromises > that at least compiled on Windows. Sounds like pushing sand up a hill or herding cats. I'll pass for now. > >Since our Windows support is "client" mode only do loops matter? > > Yes, to the extent that the Windows client will support a local > repository. It may be true that the loops are impossible on Windows > since links are not processed in the same way. We address this topic later in this message thread. > Regards, Ditto, > Derek Conrad ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: Feature Branch Windows Build Broken - lib/canonicalize.c - ELOOP & lstat
Hi Derek, > From: Derek Price > > Are stat and lstat really equivalent on Windows? Windows Visual C doesn't implement "lstat" in any fashion. The "wnt_lstat" function in "windows-NT/filesubr.c" appears to call "lstat" but that is a macro defined to "stat" in "lib/system.h" which is included in "cvs.h" which is included by "windows-NT/filesubr.c". The point is easily proved by either of: #undef lstat or #define lstat statxx just before the "wnt_lstat" function definition. The former produces a link error: unresolved external symbol _lstat The latter produces a warning: "lstat" macro redefinition in... > >Index: lib/system.h > >=== [snip] > >-#ifndef S_ISLNK > >+#if !defined(lstat) && !defined(S_ISLNK) > > # define lstat stat > > #endif > > I suspect this was only relevant on Windows anyhow and the entire block > can be removed. That is the macro Windows has previously relied upon for "lstat". We can drop it only if we do the same or similar somewhere else. > >Index: windows-NT/config.h.in.footer > >=== [snip] > >-#define CVS_STAT wnt_stat > >-int wnt_stat (); > >- > >-#define CVS_LSTAT wnt_lstat > >-int wnt_lstat (); > >+int wnt_stat (const char *file, struct wnt_stat *sb); > > This may prove unnecessary. See below. I didn't see anything pertinent below. What did I miss? > >+ > >+/* Windows has no ELOOP value in errno.h */ > >+#define ELOOP 1 > > How about #define ELOOP EMLINK? At least if this error ever comes up, > sterror will then produce a somewhat meaningful error message on Windows. I like it!!! > >Index: windows-NT/config.h.in.in > >=== [snip] > >-/* Define if gettimeofday clobbers localtime's static buffer. */ > >-#undef GETTIMEOFDAY_CLOBBERS_LOCALTIME_BUFFER > > Why are you removing these lines? Yes, macro "GETTIMEOFDAY_CLOBBERS_LOCALTIME_BUFFER" is no longer used. The "mkconfig.pl" script detects more than it reports. I enable a full check whenever working on Windows "config.h" and inputs. This time it reported this macro no longer appears in root "config.h.in" and a grep of the source tree confirms it is unused. --- We're missing part of your response regarding "This may prove..." from above so I take it we're not ready to commit a patch just yet. > Cheers, Ditto, > Derek Conrad ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature Branch Windows Build Broken - lib/canonicalize.c - ELOOP & lstat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Conrad T. Pino wrote: >>>-#define CVS_STAT wnt_stat >>>-int wnt_stat (); >>>- >>>-#define CVS_LSTAT wnt_lstat >>>-int wnt_lstat (); >>>+int wnt_stat (const char *file, struct wnt_stat *sb); >> >>This may prove unnecessary. See below. > > >I didn't see anything pertinent below. What did I miss? The new stat module is going to define gl_stat and gl_lstat and provide protos for rpl_stat and rpl_lstat in a header. The easiest thing to do is probably going to just use the new header and rename the windows-NT/filesubr.c functions to rpl_stat and rpl_lstat. Also, the stat function in glob.c is not using the timestamps, which is all the windows-NT/filesubr.c functions mess with, so it will probably be okay to leave its call to stat (as opposed to gl_stat) alone. Anyhow, dealing with this should probably wait until Bruno commits his changes to the stat module and I can import the new version from GNULIB. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFClOMyLD1OTBfyMaQRAvk2AJ92UnrvZa0t7EkMSGwUnRYDtc5V/QCg2+EB Smt2Qff7F7CeziS2jhOanoM= =+Ysi -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: Feature Branch Windows Build Broken - lib/canonicalize.c - ELOOP & lstat
Hi Derek, > From: Derek Price > > The new stat module is going to define gl_stat and gl_lstat and provide > protos for rpl_stat and rpl_lstat in a header. The easiest thing to do > is probably going to just use the new header and rename the > windows-NT/filesubr.c functions to rpl_stat and rpl_lstat. I discarded the "wnt_lstat" function and "windows-NT/config.h.in.in" contains "#define stat lstat" which is the same as "lib/system.h" file. As we agreed "windows-NT/config.h.in.in" does "#define stat wnt_stat". > Also, the stat function in glob.c is not using the timestamps, which is > all the windows-NT/filesubr.c functions mess with, so it will probably > be okay to leave its call to stat (as opposed to gl_stat) alone. If timestamps aren't used then we don't need "wnt_stat" nor "rpl_stat" since the platform "stat" implementation should work. > Anyhow, dealing with this should probably wait until Bruno commits his > changes to the stat module and I can import the new version from GNULIB. I committed so the Windows build completes and lowered the warnings count. > Regards, Ditto, > Derek Conrad ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
