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 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: [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: [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: 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 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
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.12grep -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: [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
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: 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 dirent.h 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 - 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 io.h 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
