Re: Feature Branch Windows Build - lib/dup-safer.c & dup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Conrad T. Pino wrote: >Hi All, > >The "dup" function call in "lib/dup-safer.c" has no >prototype included. Windows Visual C 6.0 does NOT >implement "dup" but does implement "_dup" as: > > int _dup( int handle ); > >I've added "#define dup _dup" to "config.h" chain >but Microsoft provides the prototype in "" >which is NOT referenced in "lib/dup-safer.c" and >perhaps should be. Are you willing to take this up on GNULIB? >I don't know the "m4" stuff and can't provide the >complete solutions. Suggestions are welcome. This won't matter since the configure stuff doesn't run on Windows anyhow. We just need to get the correct define, in this case probably HAVE_IO_H, into config.h and only include it when it is present in dup-safer.c. >The warning is below and it could be ignored since >the assumed and actual return types are the same. Alternatively, you could just provide the prototype in config.h.in.footer too. Cheers, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFClOaWLD1OTBfyMaQRAgeeAKCW+h10H3ycXyKVp6x4c4zNASzlDACfZYuM EKdxgEAkk+A4uJ95YOcxz8g= =0WDE -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Feature Branch Windows Build - lib/dup-safer.c & dup
Hi All, The "dup" function call in "lib/dup-safer.c" has no prototype included. Windows Visual C 6.0 does NOT implement "dup" but does implement "_dup" as: int _dup( int handle ); I've added "#define dup _dup" to "config.h" chain but Microsoft provides the prototype in "" which is NOT referenced in "lib/dup-safer.c" and perhaps should be. I don't know the "m4" stuff and can't provide the complete solutions. Suggestions are welcome. The warning is below and it could be ignored since the assumed and actual return types are the same. Best regards, Conrad Pino dup-safer.c h:\conrad\projects\cvs-1.12\lib\dup-safer.c(48) : warning C4013: '_dup' undefined; assuming extern returning int ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature Branch Windows Build Broken - lib/glob.c & WINDOWS32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Conrad T. Pino wrote: >Oops, I forgot the error message which follows. > >Compiling... >glob.c >h:\conrad\projects\cvs-1.12\lib\glob.c(535) : warning C4013: 'sysconf' undefined; assuming extern returning int >h:\conrad\projects\cvs-1.12\lib\glob.c(535) : error C2065: '_SC_LOGIN_NAME_MAX' : undeclared identifier I've checked in what I hope is a fix for this. >h:\conrad\projects\cvs-1.12\lib\glob.c(1171) : warning C4133: ':' : incompatible types - from 'struct direct *' to 'struct dirent *' >h:\conrad\projects\cvs-1.12\lib\glob.c(1171) : warning C4133: 'initializing' : incompatible types - from 'struct dirent *' to >'struct direct *' Is it too much to hope for that Windows has and implements the readdir() family of functions and defining HAVE_DIRENT_H would be enough here? Cheers, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFClN+OLD1OTBfyMaQRAi6LAJ0WECXd7eJETb52st5XbAcwTPsCyACg61oc X0Mj+ydzrG/osYJ1DCtmIWo= =2GBK -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
-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/glob.c & WINDOWS32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Conrad T. Pino wrote: >Hi Derek, > >The latest "lib/glob.c" introduced new macros not addressed >in the m4 stuff. Of interest are "WINDOWS32" and perhaps >"__MSDOS__" as "#define" and "#undef" respectively. > >Should I be expecting an "m4" solution which means I edit No. >"windows-NT/config.h.in.in" or not which means I edit the >"windows-NT/config.h.in.footer" instead? This stuff was cut and pasted from the glibc glob.c file. Isn't __MSDOS__ defined automatically by some compilers? Considering that I cannot find WINDOWS32 in any of the glibc header files, I would expect WINDOWS32 to be defined similarly. Looking at the code that is switching on those symbols, it looks mostly like directory stuff to allow C:/ style paths, so if it turns out not to be defined by your compiler it should be pretty harmless to just define one or the other for now there. I'm not so sure about the CONVERT_D_INO stuff and REAL_DIR_ENTRY stuff. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFClNzILD1OTBfyMaQRAuSaAKDfMOkgRHtBMgGWgDqIgtUS/WA1bACg8OYB yCCGQzMwcmEGpQQ6SeW6iv4= =oD74 -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature Branch Solaris Build Broken - lib/glob.c errors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Conrad T. Pino wrote: >I loaded the gcc 2.95 compiler for the sole purpose of compiling CVS on >this platform since previously CVS Home didn't offer a binary for this >platform. I loaded the gcc 3.4 compiler for the sole purpose of fixing >the CVS compile on this platform. I assume both versions can coexist >with appropriate configuration. I turn the questions around: Does what I just checked in work for you on Solaris? >How can we use both versions to the CVS Project's advantage? >Which version should be canonical for next binary release? With luck, it doesn't matter now. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFClNl3LD1OTBfyMaQRAuw0AKCNgFRpezLlLdiqkdB20fWAgTc+YwCeK08B 0w1T6Fqgvd+DX2ysEtKdNAQ= =Zx0Q -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: [bug-gnulib] New GNULIB glob module?
Larry Jones wrote: >Derek Price writes: > > >>Larry, can you tell us if defining >>_POSIX_PTHREAD_SEMANTICS would work to get the POSIX version of >>getpwnam_r on Solaris? >> >> > >It looks like it. > > I've committed Paul's patch to the CVS CVS tree, as well as removing the associated glob.c changes, and I will install it in GNULIB if it passes CVS nightly testing on Solaris. Regards, Derek ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Feature Branch Windows Build Broken - lib/glob.c & WINDOWS32
Hi Derek, The latest "lib/glob.c" introduced new macros not addressed in the m4 stuff. Of interest are "WINDOWS32" and perhaps "__MSDOS__" as "#define" and "#undef" respectively. Should I be expecting an "m4" solution which means I edit "windows-NT/config.h.in.in" or not which means I edit the "windows-NT/config.h.in.footer" instead? A grep for "WINDOWS32" follows below. Conrad H:\Conrad\Projects\cvs-1.12>grep -dn WINDOWS32 *.c File lib\glob.c: 112 # if (defined POSIX || defined WINDOWS32) && !defined __GNU_LIBRARY__ 134 #if (defined POSIX || defined WINDOWS32) && !defined __GNU_LIBRARY__ 413 #if defined __MSDOS__ || defined WINDOWS32 420 #endif /* __MSDOS__ || WINDOWS32 */ 457 #if defined __MSDOS__ || defined WINDOWS32 481 #if defined __MSDOS__ || defined WINDOWS32 527 # ifdef WINDOWS32 592 # endif /* WINDOWS32 */ 607 # if !defined _AMIGA && !defined WINDOWS32 682 # endif /* Not Amiga && not WINDOWS32. */ 935 #if defined __MSDOS__ || defined WINDOWS32 946 #if defined __MSDOS__ || defined WINDOWS32 ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: Feature Branch Windows Build Broken - lib/glob.c & WINDOWS32
Oops, I forgot the error message which follows. Compiling... glob.c h:\conrad\projects\cvs-1.12\lib\glob.c(535) : warning C4013: 'sysconf' undefined; assuming extern returning int h:\conrad\projects\cvs-1.12\lib\glob.c(535) : error C2065: '_SC_LOGIN_NAME_MAX' : undeclared identifier h:\conrad\projects\cvs-1.12\lib\glob.c(1171) : warning C4133: ':' : incompatible types - from 'struct direct *' to 'struct dirent *' h:\conrad\projects\cvs-1.12\lib\glob.c(1171) : warning C4133: 'initializing' : incompatible types - from 'struct dirent *' to 'struct direct *' Error executing cl.exe. ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: Feature Branch Solaris Build Broken - lib/glob.c errors
Hi Derek, > From: Derek Price > > >A gcc upgrade sure helps. I installed gcc 3.4.2 binary from SunFreeWare.\ > > I brought up changes to the GNULIB stat module up on bug-gnulib and > found out that this problem has been encountered before. GNULIB is > going to continue supporting the older gccs without the fix you found in > 3.4.2, so I have updated the glob.c file to use struct_stat64 in place > of struct stat, and #defined struct_stat64 to struct stat64 or struct > stat as appropriate. Does this work for you with whichever compiler you > choose to stick with? I'd like to suggest defining "struct_name" with a "typedef" instead of a "#define" as the preprocessor is recursive and a "struct stat" macro value will still be substituted by "#define stat ..." macro. I loaded the gcc 2.95 compiler for the sole purpose of compiling CVS on this platform since previously CVS Home didn't offer a binary for this platform. I loaded the gcc 3.4 compiler for the sole purpose of fixing the CVS compile on this platform. I assume both versions can coexist with appropriate configuration. I turn the questions around: How can we use both versions to the CVS Project's advantage? Which version should be canonical for next binary release? > 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
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: [bug-gnulib] New GNULIB glob module?
Derek Price writes: > > Larry, can you tell us if defining > _POSIX_PTHREAD_SEMANTICS would work to get the POSIX version of > getpwnam_r on Solaris? It looks like it. -Larry Jones I never get to do anything fun. -- Calvin ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: [bug-gnulib] New GNULIB glob module?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Eggert wrote: >Derek Price <[EMAIL PROTECTED]> writes: > >>+# ifdef HAVE___POSIX_GETPWNAM_R >>+ /* Solaris. */ >>+# define getpwnam_r(name, bufp, buf, len, res) \ >>+ __posix_getpwnam_r (name, bufp, buf, len, res) >>+# endif > > >I don't see why this is needed. The Solaris include files already >contain the magic necessary to convert getpwnam_r to >__posix_getpwnam_r, right? Or is it because that depends on >_POSIX_PTHREAD_SEMANTICS? If so, why not define that, as follows? I >don't see why any gnulib-using application would want the nonstandard >Solaris versions of the *_r functions. > >--- extensions.m4.~1.6.~ 2005-02-23 05:49:36 -0800 >+++ extensions.m4 2005-05-24 12:35:48 -0700 >@@ -21,6 +21,10 @@ AC_DEFUN([gl_USE_SYSTEM_EXTENSIONS], [ > [/* Enable extensions on Solaris. */ > #ifndef __EXTENSIONS__ > # undef __EXTENSIONS__ >+#endif >+#ifndef _POSIX_PTHREAD_SEMANTICS >+# undef _POSIX_PTHREAD_SEMANTICS > #endif]) > AC_DEFINE([__EXTENSIONS__]) >+ AC_DEFINE([_POSIX_PTHREAD_SEMANTICS]) > ]) I really have no idea. Larry, can you tell us if defining _POSIX_PTHREAD_SEMANTICS would work to get the POSIX version of getpwnam_r on Solaris? Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFClKxWLD1OTBfyMaQRAot/AKDvKB48aoCE0kys6bB3zxx0KT06sACgijeV z/hTtSVzW3MRjWbCzAZy7pg= =4CER -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature Branch Solaris Build Broken - lib/glob.c errors
Conrad T. Pino wrote: >Hi Derek, > > > >>From: Conrad T. Pino >> >> >> >>>From: Derek Price >>> >>>Perhaps the problem is in your GCC installation or usage? >>> >>> > >A gcc upgrade sure helps. I installed gcc 3.4.2 binary from SunFreeWare.\ > > I brought up changes to the GNULIB stat module up on bug-gnulib and found out that this problem has been encountered before. GNULIB is going to continue supporting the older gccs without the fix you found in 3.4.2, so I have updated the glob.c file to use struct_stat64 in place of struct stat, and #defined struct_stat64 to struct stat64 or struct stat as appropriate. Does this work for you with whichever compiler you choose to stick with? 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
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
