Windows Build - lib/canonicalize.c lib/filenamecat.h
Hi Derek, The following patch raises an interesting temptation: https://ccvs.cvshome.org/servlets/ReadMsg?list=cvsmsgNo=3877 Conditional compilation on Windows compiles code that doesn't use the file_name_concat function which lead me to omit the file lib/filenamecat.c from the libcvs project. However the '#include filenamecat.h' in lib/canonicalize.c is unconditional triggering VC6 to create a false dependency. Does surrounding the '#include ...' in lib/canonicalize.c with the same conditional compilation logic as found later on in the same file seem useful to the project as a whole? A patch with the change I'm considering follows below. Conrad -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Sunday, June 12, 2005 13:37 To: [EMAIL PROTECTED] Subject: CVS update: /ccvs/lib/ User: conradpino Date: 05/06/12 13:37:14 Modified: /ccvs/lib/ ChangeLog, libcvs.dep, libcvs.dsp, libcvs.mak Log: * libcvs.dsp: Add files filenamecat.h and lstat.c to project. * libcvs.dep, libcvs.mak: Regenerate for libcvs.dsp changes. File Changes: [snip] Index: lib/canonicalize.c === RCS file: /cvs/ccvs/lib/canonicalize.c,v retrieving revision 1.2 diff -u -p -r1.2 canonicalize.c --- lib/canonicalize.c 10 Jun 2005 20:30:20 - 1.2 +++ lib/canonicalize.c 13 Jun 2005 20:21:06 - @@ -48,7 +48,9 @@ void free (); #include stddef.h #include cycle-check.h +#if !HAVE_CANONICALIZE_FILE_NAME HAVE_RESOLVEPATH #include filenamecat.h +#endif /* !HAVE_CANONICALIZE_FILE_NAME HAVE_RESOLVEPATH */ #include stat-macros.h #include xalloc.h #include xgetcwd.h Index: lib/libcvs.dep === RCS file: /cvs/ccvs/lib/libcvs.dep,v retrieving revision 1.28 diff -u -p -r1.28 libcvs.dep --- lib/libcvs.dep 12 Jun 2005 20:37:12 - 1.28 +++ lib/libcvs.dep 13 Jun 2005 20:21:06 - @@ -31,7 +31,6 @@ .\canonicalize.h\ .\cycle-check.h\ .\dev-ino.h\ - .\filenamecat.h\ .\pathmax.h\ .\stat-macros.h\ .\timespec.h\ Index: lib/libcvs.dsp === RCS file: /cvs/ccvs/lib/libcvs.dsp,v retrieving revision 1.27 diff -u -p -r1.27 libcvs.dsp --- lib/libcvs.dsp 12 Jun 2005 20:37:12 - 1.27 +++ lib/libcvs.dsp 13 Jun 2005 20:21:06 - @@ -364,10 +364,6 @@ SOURCE=.\exitfail.h # End Source File # Begin Source File -SOURCE=.\filenamecat.h -# End Source File -# Begin Source File - SOURCE=.\fnmatch.h # End Source File # Begin Source File ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Conditional/Comment Error? lib/canonicalize.c
Can someone suggest which one of the following 2 changes (if any)
is the best one to commit?
Index: lib/canonicalize.c
===
RCS file: /cvs/ccvs/lib/canonicalize.c,v
retrieving revision 1.2
diff -u -p -r1.2 canonicalize.c
--- lib/canonicalize.c 10 Jun 2005 20:30:20 - 1.2
+++ lib/canonicalize.c 13 Jun 2005 20:32:04 -
@@ -69,7 +69,7 @@ void free ();
char *
canonicalize_file_name (const char *name)
{
-# if HAVE_RESOLVEPATH
+# if !HAVE_RESOLVEPATH
char *resolved, *extra_buf = NULL;
size_t resolved_size;
@@ -130,7 +130,7 @@ canonicalize_file_name (const char *name
return canonicalize_filename_mode (name, CAN_EXISTING);
-# endif /* !HAVE_RESOLVEPATH */
+# endif /* HAVE_RESOLVEPATH */
}
#endif /* !HAVE_CANONICALIZE_FILE_NAME */
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: Build CVS (TRUNK) failed.
Hi, Please test for the existence of: directory: windows-NT/sys new file: windows-NT/sys/types.h I hope this is an update oversight that: cvs update -dP windows-NT will correct. If none of the above is true then please send me Microsoft's sys/types.h file from your compiler INCLUDE path. At a command prompt run: cl /? out.txt 2 err.txt send the err.txt file and delete out.txt. Thank you, Conrad Pino -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 01, 2005 00:01 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Build CVS (TRUNK) failed. ..\windows-NT\unistd.h(34) : error C2282: 'pid_t' is followed by 'getpid' (missing ','?) ..\windows-NT\unistd.h(37) : error C2146: syntax error : missing ')' before identifier 'microseconds' ..\windows-NT\unistd.h(37) : error C2501: 'microseconds' : missing decl-specifiers dup-safer.c(51) : fatal error C1004: unexpected end of file found [snip] ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Feature Branch - windows-NT/pwd.h windows-NT/unistd.h
Hi Derek, File windows-NT/pwd.h declares several functions that are declared in unistd.h according to the NetBSD man pages. Since I created windows-NT/unistd.c do you object in principle to migrations from pwd.c to unistd.c? If you agree, I'll enumerate the functions to migrate for review before actually doing so. Best regards, Conrad ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Windows 2000 - HOMEDRIVE,HOMEPATH vs. USERPROFILE
Hi Derek, I ran tests on Windows 2000 and here's what I've learned so far: * User accounts have two flavors: Local and Domain * Both user account types support local or network user profiles * Both user account types support Home folder options * User profile type (local vs. network) seems irrelevant to CVS because network profiles are copied to a local drive and USERPROFILE always points to the local copy located in the machine specific profile root directory. * Home Folder options are undefined, local folder, network folder and these are visible to CVS as follows: Home Folder Environment Variables undefined %HOMEDRIVE%%HOMEPATH% set to %USERPROFILE% HOMESHARE does not exist local folder%HOMEDRIVE% set to local folder drive, no path %HOMEPATH% set to local folder path, no drive HOMESHARE does not exist network folder %HOMEDRIVE% set to network drive %HOMEPATH% set to \ %HOMESHARE% set to network folder * Network folder values look like: \\ServerName\ShareName\OptionalPath Based on these observations, how do Windows and UNIX differ to CVS? UNIX user profile (.profile,.bash_profile) files are always in $HOME. UNIX user profile changes are effective AND committed when changed. Windows user profile is always local and independent of Home Folder. Windows Home Folder is synchronized with the user profile only when: Home Folder is undefined Home Folder local path == %USERPROFILE% Windows user profile changes are effective when changed and committed ONLY when user the logs off. Best regards, Conrad Pino ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: Windows 2000 - HOMEDRIVE,HOMEPATH vs. USERPROFILE
Hi Derek, A few more observations follow: From: Conrad T. Pino [mailto:[EMAIL PROTECTED] Based on these observations, how do Windows and UNIX differ to CVS? UNIX user profile (.profile,.bash_profile) files are always in $HOME. UNIX user profile changes are effective AND committed when changed. UNIX $HOME changes are effective AND committed when changed. Windows user profile is always local and independent of Home Folder. Windows Home Folder is synchronized with the user profile only when: Home Folder is undefined Home Folder local path == %USERPROFILE% Windows user profile changes are effective when changed and committed ONLY when user the logs off. The last sentence above needs clarification as follows: Windows local user profile changes are effective AND committed when changed. Windows network user profile changes are effective when changed and committed ONLY when user the logs off. Windows network user profile commits may not persist as expected when used on multiple machines: Login to workstation one, copy network profile to local drive. Login to workstation two, copy network profile to local drive. Modify user profile on workstation two. Logoff workstation two, copy local drive to network profile, network profile has workstation two modification. Logoff workstation one, copy local drive to network profile, workstation two modification to network profile is lost since the Microsoft help file says: If you use a roaming profile on more than one computer simultaneously, it will preserve the settings from the last computer that logs off. Windows Home Folder changes are effective AND committed when changed. Conrad ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: windows-NT/pwd.c - struct passwd - Home Directory
Hi Derek,
From: Derek Price
What I don't understand is why . is a reasonable home directory according
to the getpwuid implementation:
static char *home_dir = .; /* we feel (no|every)where at home */
I don't agree that it is. I think it was a poor, arbitrary
implementation decision at some point in the past before Windows had the
concept of a home dir, which did not show up until NT, I believe.
Thank you. We agree . is arbitrary and not particularly useful.
My thought was along the lines of:
struct passwd *
getpwuid (int uid)
{
pw.pw_name = getlogin ();
- pw.pw_dir = home_dir;
+ pw.pw_dir = get_homedir ();
pw.pw_shell = login_shell;
pw.pw_uid = 0;
return pw;
}
I concluded get_homedir wasn't suitable in the above case because
get_homedir in src/filesubr.c processed the HOME variable.
I created woe32_home_dir in windows-NT/woe32.c to provide only
the Windows view of the home directory and kept the delegation of
HOME processing within get_homedir. The windows-NT versions
of getpwuid and get_homedir both rely upon woe32_home_dir.
If the getpwuid function in windows-NT/pwd.c worked, then the
get_homedir in src/filesubr.c might be moved into src/subr.c and shared
with the Windows implementation, or so I was thinking.
We agree on the implied goal of reducing code redundancy.
I wasn't aware src/subr.c was a possibility for merging back code.
I'll consider src/subr.c when making future prospsals. Thanks
The commits I've bring a get_homedir migration to src/subr.c within
the possible on Windows. The issue then becomes:
H:\Conrad\Projects\cvs-1.12-editgrep -dn get_homedir filesubr.c
File emx\filesubr.c:
703 get_homedir ()
File os2\filesubr.c:
755 get_homedir ()
File src\filesubr.c:
803 get_homedir (void)
File vms\filesubr.c:
907 get_homedir ()
File windows-NT\filesubr.c:
767 get_homedir (void)
H:\Conrad\Projects\cvs-1.12-edit
what to do about (emx,os2,vms)/filesubr.c versions. Unless you know
these are a slam dunk right now, I suggest deferral until I complete
the items I've begun.
Regardless, I do think this basic idea is correct. My reconsideration
is that perhaps all user-settable environment variable references,
should be in get_homedir, and getpwuid would need to return the secure
home directory, as it is defined to on UNIX, where it is often read from
the /etc/passwd file, for instance. The closest thing might be the
value from the registry on Windows. Windows must read this from
somewhere in order to set USERPROFILE, HOMEDRIVE, and HOMEPATH on boot.
You need to read the Windows specifications and determine where these
values are coming from to implement this correctly. Is there no
equivalent to this function on Windows, where the home dir value may
have come from a domain server or whatever?
I believe this is the Windows research starting point:
http://msdn.microsoft.com/library/en-us/dnanchor/html/securityanchor.asp
As you might surmise it's a substantial amount of material.
I suggest finishing the simple reorganizing I have in progress and I'll
make sure your suggestion is implementable.
The UNIX specification for getpwuid is here:
http://www.opengroup.org/onlinepubs/009695399/functions/getpwuid.html.
Another thought can take use one step closer to using src/filesubr.c
instead
of windows-NT/filesubr.c by defining wnt_homedir in woe32.c:
Already implemented as woe32_home_dir in woe32.c file.
This would be fine if we decide the proper place for all env var lookups
is in get_homedir.
This question is on the border between CVS and platform. I don't know CVS
internals well enough to risk an opinion. I look to you and CVS developers
to impose requirements the platform compatability layer must meet.
I've seen enough to conclude that non UNIX/POSIX compliant expedient hacks
eventually become problematic later. Your work with GNULib has focused
my ideas for contributing towards using windows-NT project to fill in the
missing UNIX/POSIX functionality GNULib requires and Microsoft doesn't
provide.
A grep of get_homedir usage (below) leads me to believe that whichever way
we choose, functions getpwuid and get_homedir should present a
consistent
view of where the home directory is on a given platform.
Once again, to summarize, if getpwuid is to be implemented,
functionality should be divided as follows:
getpwuid: to POSIX spec as much as possible, secure source if possible,
output not user settable
get_homedir: to CVS requirements, uses env vars, possibly set by user
I accept the requirement in principle but I don't see the path to a complete
implementation right now. I'm sure I'll see more as we move forward. I will
review your reply to my report on Windows 2000 behavior which I'm aware of but
is unread as I write before commenting in depth.
I plan to finish what I can see which is a
RE: CVS update: /ccvs/windows-NT/
Hi Derek, From: Derek Price Log: * unistd.c, unistd.c: Add new usleep function using my_usleep logic taken from woe32.c file. * woe32.c, woe32.h: Add new (woe32_home_dir,woe32_shell) functions. * woe32.c: Modify woe32_nanosleep to use unistd.h usleep. Glancing at lib/nanosleep.c, the usleep() implementation in windows-NT/unistd.c, and based on the fact that signal() and select() appear to be used elsewhere in windows-NT/*.c, it looks like lib/nanosleep.c would compile on Windows with the right config.h.in.in definitions. Then the woe32_nanosleep and unistd.c usleep could be removed in favor of the rpl_nanosleep in lib/nanosleep.c. The timer code in lib/nanosleep.c looks very good but I'm uncomfortable making a commitment to making the change because: * I don't understand UNIX style signal behavior well. * I don't know how to verify the change is no worse than current. * Even though CVS doesn't use usleep I'd like to keep it for now as the best candidate to implement the millisecond resolution Windows supports in case Microsoft's select implementatino is ill behaved. * I haven't proven to myself the actual time out granularity of Microsoft's select implementation and some cases I've contemplated suggest another choice. Let me share some things I've learned about Windows and process delays: * Windows native API Sleep call is a real time programming joke. It specifies millisecond resolution but always surrenders balance of the current time slice: http://msdn.microsoft.com/library/en-us/dllproc/base/sleep.asp On a busy system your process runs at the hardware timer tick rate which is the standard PC BIOS rate of 18+ ticks per second. * Millisecond resolution delays without surrendering the time slice are possible by creating an unsignaled Event then waiting for that Event with a time out value. This feature requires hardware support in CPU otherwise behavior reverts to the PC BIOS rate. I'll work up a test program to measure select time out granularity in the next few days. I'll support you to the best I can should you choose to make the change. Can you share some ideas on what I need to do to get sanity.sh to run on Windows 2000? Does the MKS Tool Kit sh implementation help any? Is Windows 2000 bash combined with MKS Took Kit a better start? * filesubr.c: Modify get_homedir to use woe32_home_dir. * pwd.c: Modify getpwuid to use woe32_home_dir woe32_shell. Append USERNAME to login_strings array. Again, unless USERNAME is a read-only env var, if there is a Windows API for retrieving these sorts of values, it should probably be used in the POSIX replacements in favor of writable environment variables. I agree in principle but several things indicate this is a non-issue: * Microsoft's workstation security practices commonly grant the CVS user root equivalent privilege on the executing platform. Why infringe on the user's right to destroy local resources since they're effectively all owned by the workstation user? * The better security route indicates we should remove login_strings altogether since the addition/removal of a single variable doesn't close the security vulnerability. Windows NT and kin implement environment variables in three layers: 1. System environment variabiles require Administrator privilege to modify and most users are workstation Administrators. These are persisted in the system registry 2. User environment variables. These are persisted in the user profile registry. 3. Process environment variables. The process set is built from System and User values preferring the User value in some cases or concatenating others like %PATH% placing the User value before the System value. The process is then free to mangle with no restrictions. Child processes inherent from parent when spawned. My suggestions are: - Remove login_strings support altogether OR - Leave USERNAME since it subtracts nothing and adds a bit. What does CVS do with getlogin value that raise security threats? 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/glob.c WINDOWS32
Hi Derek, From: Derek Price I propose we do both, I'll edit and test, you coach: Sure. Great. I plan to stretch this out and finish in about a week. I will improve pwd.c also so long as cutting and pasting is acceptable between pwd.c and glob.c is acceptable. Hrm? Cutting and pasting in which direction. You can try and get the pwd.c module into GNULIB it might work. I just ran across the GNULIB execute module which seems to have some Windows specific code. The macros stuff is already in GNULIB, so if you could abstract some of the Windows specific stuff out into those macros, I think it can only simplify. We have the greatest freedom in pwd.c which is where I'll start. Once we are happy with what we've done for ourselves then we can decide what should be pasted back into glob.c for submission to GLib and GNULib teams. I'm not sure why earlier CVS developers missed the %USERPROFILE% value then, unless it was missing in earlier versions of NT, but if you say so... Anyhow, if we leave %HOMEDRIVE%%HOMEPATH% as a fallback value, it shouldn't be a big deal to add the new handling. I suggest using %USERPROFILE% only as the next fall back for cases where any of %HOMEDRIVE%%HOMEPATH% are missing. We've documented: %HOME% %HOMEDRIVE%%HOMEPATH% and anything we do now should have lower priority. Why even process ALLUSERSPROFILE here? As long as %USERPROFILE% and %HOMEDRIVE%%HOMEPATH% are susually set, then if they are unset then something is wrong, I would think. It just doesn't sound like a reasonable fallback to me. The UNIX fallback, or even secure method is to read the /etc/passwd file. Maybe the closest fallback on Windows is to read the registry? If all of %HOME%, %HOMEDRIVE%%HOMEPATH%, %USERPROFILE% are missing then we are indeed down to very improbable cases. I introduced %ALLUSERSPROFILE% only as another fallback that's a better alternative to hard coded values. Power users to modify the registry can relocate their profile away from the default profile root. Networked users with file server resident profiles is another case. True. Is %USERPROFILES% the best we can do here? I believe the %HOMEDRIVE%%HOMEPATH% == %USERPROFILE% will hold and plan to test both cases. I will modify a local profile and create a file server resident profile to test these cases. Windows has no support for ~ and similar. We can provide it as a reference to $HOME, $USERPROFILE and/or $HOMEDRIVE, $HOMEPATH combination. As part of glob, and to support consistent usage in CVS config files, supporting ~ still seems reasonable. Determining what that means is up to us. CVS supported the non-standard $HOME on Windows 95/98/ME because there was nothing standard. It is possible that continuing to support that for glob is fine sine it won't normally be set anyhow, but what we should aim at is whatever seems morally closest in Windows. Agreed. Newest is probably best, from the standpoint of supporting what Microsoft declares most current first. Supporting the legacy stuff in chronologically reverse order should manage to support both old systems and those who unset their %USERPROFILE% to allow their old setup, which knew how to deal with %HOMEDRIVE%%HOMEPATH%, or whatever, to work. I'll enumerate a list of possibilities shortly and then we can order them. Is %USERPROFILE% and %HOMEDRIVE%%HOMEPATH% really the same thing? Now that you have me talking about it, old memories that say the %USERPROFILE% was just the equivalent of the UNIX .login script are starting to surface. Other than user intervention I believe so but will continue testing it as an unproven hypothesis. I assume my suggestion to use the registry is not needed based upon the lack of feedback and the use of native Win32 API calls likely to create resistance from GLib and GNULib. Like I said, maybe we can get it in, especially if it is a new module. Even if it isn't a new module, then we can support it in CVS, regardless, and the effort is not a complete waste. If GNULIB folks ever need it they can swipe it at their convenience. There is no environment variable to locate the Default User profile. I consider that only because the current glob.c hard coded value is a now obsolete reference to that profile. The registry is the only way to locate the Default User profile and the default root directory for creating local profiles. I'm not proposing we use these and enumerated them as alternatives to consider. Earlier in this message I committed to preparing as list of possibilities and will includes these for discussion purposes. I deliberately ignored Windows 95, 98 and Me when writing the drasft as I have not worked with any of these systems in years. I don't care but will include them consist with CVS Project policy whatever that may be. Can you share an opinion here? Again, supporting %HOME% was the best CVS came up with, and that was even non-standard
RE: CVS update [cvs1-11-x-branch]: /ccvs/windows-NT/
Hi Derek, From: Derek Price There is an xnrealloc function in lib/xmalloc.c. Isn't that being compiled on Windows? No, stable branch Windows build omits it because it doesn't exist. My tests (see below) say lib/xmalloc.c is on feature branch only. Cheers, Ditto, Derek Conrad H:\Conrad\Projects\cvs-1.11cvs update cvs update: Updating . cvs update: Updating contrib cvs update: Updating diff cvs update: Updating doc cvs update: Updating emx cvs update: Updating lib cvs update: Updating man cvs update: Updating os2 cvs update: Updating src cvs update: Updating tools cvs update: Updating vms cvs update: Updating windows-NT cvs update: Updating windows-NT/SCC cvs update: Updating www cvs update: Updating zlib cvs update: Updating zlib/amiga cvs update: Updating zlib/contrib cvs update: Updating zlib/contrib/asm386 cvs update: Updating zlib/contrib/asm586 cvs update: Updating zlib/contrib/asm686 cvs update: Updating zlib/contrib/delphi cvs update: Updating zlib/contrib/delphi2 cvs update: Updating zlib/contrib/iostream cvs update: Updating zlib/contrib/iostream2 cvs update: Updating zlib/contrib/minizip cvs update: Updating zlib/contrib/untgz cvs update: Updating zlib/msdos cvs update: Updating zlib/nt cvs update: Updating zlib/os2 H:\Conrad\Projects\cvs-1.11grep -dn xnrealloc *.c H:\Conrad\Projects\cvs-1.11dir lib\x*.c Volume in drive H is CTP-RAID-001 Volume Serial Number is 6897-6A9D Directory of H:\Conrad\Projects\cvs-1.11\lib 11/29/1997 14:521,669 xgetwd.c 1 File(s) 1,669 bytes 0 Dir(s) 2,332,844,032 bytes free H:\Conrad\Projects\cvs-1.11cd ..\cvs-1.12\lib H:\Conrad\Projects\cvs-1.12\libcvs log xmalloc.c RCS file: /cvs/ccvs/lib/xmalloc.c,v Working file: xmalloc.c head: 1.3 branch: locks: strict access list: symbolic names: cvs1-12-12: 1.2 newtags-root: 1.2 newtags: 1.2.0.2 cvs1-12-11: 1.2 cvs1-12-10: 1.2 writeproxy2: 1.1.0.4 cvs1-12-9: 1.1 writeproxy: 1.1.0.2 cvs1-12-8: 1.1 tmpstart: 1.1 tmpend: 1.1 cvs1-12-7: 1.1 cvs1-12-6: 1.1 keyword substitution: kv total revisions: 3; selected revisions: 3 description: revision 1.3 date: 2005/05/23 17:44:33; author: dprice; state: Exp; lines: +1 -1 * __fpending.c, alloca_.h, allocsa.c, allocsa.h, asnprintf.c, asprintf.c, basename.c, chdir-long.c, chdir-long.h, closeout.c, closeout.h, dirname.c, dirname.h, dup-safer.c, dup2.c, error.c, error.h, exit.h, exitfail.c, exitfail.h, fd-safer.c, fnmatch.c, fnmatch_.h, fnmatch_loop.c, getcwd.c, getcwd.h, getdate.c, getdate.h, getdate.y, gethostname.c, getline.c, getline.h, getndelim2.c, getndelim2.h, getnline.c, getnline.h, getopt.c, getopt1.c, getopt_.h, getopt_int.h, getpagesize.h, getpass.c, getpass.h, gettext.h, gettime.c, gettimeofday.c, lstat.c, malloc.c, md5.c, md5.h, mempcpy.c, mempcpy.h, memrchr.c, memrchr.h, minmax.h, mkdir.c, mkstemp.c, mktime.c, nanosleep.c, openat.c, openat.h, pagealign_alloc.c, pagealign_alloc.h, pathmax.h, printf-args.c, printf-args.h, printf-parse.c, printf-parse.h, quotearg.c, quotearg.h, readlink.c, realloc.c, regex.c, regex.h, rename.c, rpmatch.c, save-cwd.c, save-cwd.h, setenv.c, setenv.h, stat-macros.h, stat.c, stdbool_.h, stdint_.h, strcase.h, strcasecmp.c, strdup.c, strdup.h, strerror.c, strftime.c, strftime.h, stripslash.c, strstr.c, strstr.h, strtol.c, strtoul.c, tempname.c, time_r.c, time_r.h, timespec.h, unistd-safer.h, unlocked-io.h, unsetenv.c, vasnprintf.c, vasnprintf.h, vasprintf.c, vasprintf.h, xalloc-die.c, xalloc.h, xgetcwd.c, xgetcwd.h, xgethostname.c, xmalloc.c, xreadlink.c, xreadlink.h, xsize.h, yesno.c, yesno.h: Update from GNULIB. revision 1.2 date: 2004/10/06 00:23:22; author: dprice; state: Exp; lines: +15 -41 * Makefile.am (libcvs_a_SOURCES): Add xalloc-die.c. * xalloc-die.c: New file from GNULIB. * xalloc.h, xmalloc.c: Update from GNULIB. revision 1.1 date: 2004/02/20 21:50:12; author: dprice; state: Exp; Import xalloc module from GNULIB, as well as its remaining unimported dependency, the exitfail module. * Makefile.am (libcvs_a_SOURCES): Add new sources. * exitfail.c, exitfail.h, xalloc.h, xmalloc.c, xstrdup.c: New files. * Makefile.in: Regenerated. = H:\Conrad\Projects\cvs-1.12\lib ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: CVS update [cvs1-11-x-branch]: /ccvs/windows-NT/
Hi Derek, From: Derek Price Ah, okay. Sorry. I already forgot that I put this diff bugfix into stable and didn't read the tag on your commit. I had to make that same change to the src/run.c on stable when I ported the change from feature. :) The new functions in windows-NT/run.c are your code. The implementations came from feature branch src/run.c with one line borrowed from stable. :) Thanks, You're welcome, Derek Conrad ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Feature Branch Windows Build Broken - #include sys/cdefs.h fails
Hi Derek, I'm not recommending this as a solution since it's not a general solution but mkdir windows-NT/sys; touch windows-NT/sys/cdefs.h allows Windows build to complete with no errors and no warnings. Conrad Configuration: libcvs - Win32 Debug Compiling... glob.c Creating library... Configuration: libdiff - Win32 Debug Creating library... Configuration: cvsnt - Win32 Debug Linking... LINK : LNK6004: .\WinDebug\cvs.exe not found or not built by the last incremental link; performing full link cvs.exe - 0 error(s), 124 warning(s) ___ 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
Hi Derek,
From: Derek Price
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.
Yes, the Windows build completes. Can you explain what home_dir value
will be in the WINDOWS32 undefined logic?
How about defining WINDOWS32 and using the patch below?
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?
Yes, that's entirely too much to hope for. The Windows build fakes an
ndir.h implementation in the windows-NT director and I committed a
patch to lib/glob_.h that supports the ndir.h flavor.
The #if logic was cut from lib/glob.c lines 53 through 71 with the
extras discarded. My patch is a quick hack. I would appreciate it if
you choose to make improvements.
Cheers,
Ditto,
Derek
Conrad
Index: lib/glob.c
===
RCS file: /cvs/ccvs/lib/glob.c,v
retrieving revision 1.15
diff -u -p -r1.15 glob.c
--- lib/glob.c 25 May 2005 20:23:38 - 1.15
+++ lib/glob.c 26 May 2005 10:57:36 -
@@ -524,8 +525,45 @@ glob (const char *pattern, int flags,
home_dir = SYS:;
# else
# ifdef WINDOWS32
+ /* Windows doesn't set HOME, honor it if user sets it */
if (home_dir == NULL || home_dir[0] == '\0')
-home_dir = c:/users/default; /* poor default */
+ {
+ /* Windows sets USERPROFILE like UNIX sets HOME */
+ home_dir = getenv( USERPROFILE );
+ }
+ if (home_dir == NULL || home_dir[0] == '\0')
+ {
+ /* Windows sets APPDATA to $USERPROFILE/Application Data */
+ home_dir = getenv( APPDATA );
+ }
+ if (home_dir == NULL || home_dir[0] == '\0')
+ {
+ /* Windows sets ALLUSERSPROFILE to $USERPROFILE/../All
Users */
+ home_dir = getenv( ALLUSERSPROFILE );
+ }
+ if (home_dir == NULL || home_dir[0] == '\0')
+ {
+ /* Windows sets SystemRoot to installation value typically
+C:/WinNT but frequently C:/Windows */
+ /* This may be a bad idea but it's an alternative to the root
*/
+ home_dir = getenv( SystemRoot );
+ }
+ if (home_dir == NULL || home_dir[0] == '\0')
+ {
+ /*$SystemDrive/users is Windows NT 4 specific
+
+ NEW INSTALLS of Windows 2000 and later use
+ $SystemDrive/Documents and Settings
+
+ UPGRADES use previous location
+
+ The default user profile can't be found with an
environment
+ variable. It's location is in the Windows
registry.
+
+ The SystemDrive environment variable is an
alternative.
+ */
+ home_dir = c:/users/default; /* poor default */
+ }
# else
if (home_dir == NULL || home_dir[0] == '\0')
{
___
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
Hi Derek, From: Derek Price 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? Yes, if we still need it but I found another approach. 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. It turns out these prototypes are expected in unistd.h file. The platform doesn't have it so Mark and I created windows-NT/unistd.h sometime ago. I committed a patch that dropped prototypes we added in favor of including direct.h and io.h which is where Microsoft has a lot of what is normally found in unistd.h which improved the warning count significantly. 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: 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
Feature Branch Windows Build Broken - lib/canonicalize.c - ELOOP lstat
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. Currently the Windows build doesn't use the lib/stat.c module. The questions raised appear to be: 1. Where should an ELOOP definition be placed? 2. How should the ELOOP value be selected? 3. Which approach is best to resolve lib/canonicalize.c and lstat? 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. Conrad Pino Configuration: cvsnt - Win32 Debug Linking... libdiff.lib(canonicalize.obj) : error LNK2001: unresolved external symbol _lstat .\WinDebug\cvs.exe : fatal error LNK1120: 1 unresolved externals Error executing link.exe. cvs.exe - 2 error(s), 0 warning(s) Index: cvsnt.dsp === RCS file: /cvs/ccvs/cvsnt.dsp,v retrieving revision 1.30 diff -u -p -r1.30 cvsnt.dsp --- cvsnt.dsp 8 Mar 2005 05:19:52 - 1.30 +++ cvsnt.dsp 24 May 2005 18:56:39 - @@ -372,6 +372,10 @@ SOURCE=.\src\buffer.h # End Source File # Begin Source File +SOURCE=.\lib\canonicalize.h +# End Source File +# Begin Source File + SOURCE=.\src\client.h # End Source File # Begin Source File @@ -448,6 +452,10 @@ SOURCE=.\lib\gettext.h # End Source File # Begin Source File +SOURCE=.\lib\glob.h +# End Source File +# Begin Source File + SOURCE=.\src\hardlink.h # End Source File # Begin Source File Index: lib/libcvs.dsp === RCS file: /cvs/ccvs/lib/libcvs.dsp,v retrieving revision 1.23 diff -u -p -r1.23 libcvs.dsp --- lib/libcvs.dsp 17 May 2005 22:12:12 - 1.23 +++ lib/libcvs.dsp 24 May 2005 18:56:39 - @@ -97,10 +97,18 @@ SOURCE=.\basename.c # End Source File # Begin Source File +SOURCE=.\canonicalize.c +# End Source File +# Begin Source File + SOURCE=.\closeout.c # End Source File # Begin Source File +SOURCE=.\cycle-check.c +# End Source File +# Begin Source File + SOURCE=.\dirname.c # End Source File # Begin Source File @@ -308,6 +316,10 @@ SOURCE=.\allocsa.h # End Source File # Begin Source File +SOURCE=.\canonicalize.h +# End Source File +# Begin Source File + SOURCE=.\chdir-long.h # End Source File # Begin Source File @@ -320,6 +332,14 @@ SOURCE=..\windows-NT\config.h # End Source File # Begin Source File +SOURCE=.\cycle-check.h +# End Source File +# Begin Source File + +SOURCE=.\dev-ino.h +# End Source File +# Begin Source File + SOURCE=.\dirname.h # End Source File # Begin Source File @@ -426,6 +446,10 @@ SOURCE=.\gettext.h # End Source File # Begin Source File +SOURCE=.\glob.h +# End Source File +# Begin Source File + SOURCE=.\glob_.h !IF $(CFG) == libcvs - Win32 Release @@ -457,6 +481,10 @@ SOURCE=.\md5.h # End Source File # Begin Source File +SOURCE=.\mempcpy.h +# End Source File +# Begin Source File + SOURCE=..\windows-NT\ndir.h # End Source File # Begin Source File @@ -465,6 +493,10 @@ SOURCE=.\pagealign_alloc.h # End Source File # Begin Source File +SOURCE=.\path-concat.h +# End Source File +# Begin Source File + SOURCE=.\pathmax.h # End Source File # Begin Source File @@ -497,6 +529,10 @@ SOURCE=.\setenv.h # End Source File # Begin Source File +SOURCE=.\stat-macros.h +# End Source File +# Begin Source File + SOURCE=..\windows-NT\stdbool.h # End Source File # Begin Source File @@ -505,6 +541,10 @@ SOURCE=..\windows-NT\stdint.h # End Source File # Begin Source File +SOURCE=.\strdup.h +# End Source File +# Begin Source File + SOURCE=.\system.h # End Source File # Begin Source File Index: windows-NT/config.h === RCS file: /cvs/ccvs/windows-NT/config.h,v retrieving revision 1.144 diff -u -p -r1.144 config.h --- windows-NT/config.h 24 May 2005 16:38:08 - 1.144 +++ windows-NT/config.h 24 May 2005 18:56:40 - @@ -1314,3 +1314,5 @@ char *sock_strerror (int errnum); /* getpagesize is missing on Windows, but 4096 seems to do the right thing. */ #define getpagesize() 4096 + +#define ELOOP -22 ___ 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, We have a new lib/glob.c error today which I hope to understand before committing #include sys/stat.h addition to lib/glob_.h you suggested. The 3 new errors (see below) are all a single error occurring in 3 places: storage size of `st' isn't known I'm throwing this out for comment while continuing to investigate. Conrad /export/home/cvsusr/ccvs/cvs-1.12:$ make make all-recursive Making all in lib make all-am source='glob.c' object='glob.o' libtool=no \ DEPDIR=.deps depmode=gcc /bin/bash ../build-aux/depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I..-Ino/include -g -O2 -c glob.c glob.c: In function `rpl_glob': glob.c:700: storage size of `st' isn't known glob.c: In function `is_dir_p': glob.c:1046: storage size of `st' isn't known glob.c: In function `glob_in_dir': glob.c:1094: storage size of `st' isn't known *** Error code 1 make: Fatal error: Command failed for target `glob.o' Current working directory /export/home/cvsusr/ccvs/cvs-1.12/lib *** Error code 1 make: Fatal error: Command failed for target `all' Current working directory /export/home/cvsusr/ccvs/cvs-1.12/lib *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /export/home/cvsusr/ccvs/cvs-1.12 *** Error code 1 make: Fatal error: Command failed for target `all' /export/home/cvsusr/ccvs/cvs-1.12:$ ___ 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 [mailto:[EMAIL PROTECTED]
Adding #include sys/stat.h to glob_.h doesn't help with this new
error? ...
That is correct.
Neither of (1) uncondition inclusion nor (2) inclusion conditioned upon
__USE_GNU made a difference.
... I wouldn't expect this error in glob.c anyhow, since it includes
sys/types.h sys/stat.h unconditionally. According to POSIX.2,
struct stat should be defined in sys/stat.h. This same code, short of
a few recent changes, was compiling and passing tests on Solaris 8 the
other night.
This platform's sys/stat.h uses a *lot* of conditional compilation and
we may have triggered a case where no struct stat definition compiles.
I haven't proved this yet and testing this hypothesis is my next line of
investigation unless you favor another.
Can you take a quick look at this platform's sys/stat.h (below) to see
if there's something obvious to your greater experience?
Regards,
Ditto,
Derek
Conrad
/export/home/cvsusr:$ cat /usr/include/sys/stat.h
/*
* Copyright (c) 1995-1999 by Sun Microsystems, Inc.
* All rights reserved.
*/
/* Copyright (c) 1990, 1991 UNIX System Laboratories, Inc. */
/* Copyright (c) 1984, 1986, 1987, 1988, 1989, 1990 ATT */
/* All Rights Reserved */
/* THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF */
/* UNIX System Laboratories, Inc. */
/* The copyright notice above does not evidence any*/
/* actual or intended publication of such source code. */
#ifndef _SYS_STAT_H
#define _SYS_STAT_H
#pragma ident @(#)stat.h 1.2 99/05/19 SMI
#include sys/feature_tests.h
#include sys/types.h
#ifdef __cplusplus
extern C {
#endif
/*
* The implementation specific header sys/time_impl.h includes a
* definition for timestruc_t needed by the stat structure. However,
* including either time.h, which includes sys/time_impl.h, or
* including sys/time_impl.h directly will break both X/Open and
* POSIX namespace. Preceeding tag, structure, and structure member
* names with underscores eliminates the namespace breakage and at the
* same time, with unique type names, eliminates the possibility of
* timespec_t or timestruct_t naming conflicts that could otherwise
* result based on the order of inclusion of sys/stat.h and
* sys/time.h. The header sys/time_std_impl.h contains the
* standards namespace safe versions of these definitions.
*/
#if !defined(_XOPEN_SOURCE) !defined(_POSIX_C_SOURCE) || \
defined(__EXTENSIONS__)
#include sys/time_impl.h
#else
#include sys/time_std_impl.h
#endif /* !defined(_XOPEN_SOURCE) !defined(_POSIX_C_SOURCE) || ... */
#define _ST_FSTYPSZ 16 /* array size for file system type name */
/*
* stat structure, used by stat(2) and fstat(2)
*/
#if defined(_KERNEL)
/* Old SVID stat struct (SVR3.x) */
struct o_stat {
o_dev_t st_dev;
o_ino_t st_ino;
o_mode_tst_mode;
o_nlink_t st_nlink;
o_uid_t st_uid;
o_gid_t st_gid;
o_dev_t st_rdev;
off32_t st_size;
time32_tst_atime;
time32_tst_mtime;
time32_tst_ctime;
};
/* Expanded stat structure */
#if defined(_LP64)
struct stat {
dev_t st_dev;
ino_t st_ino;
mode_t st_mode;
nlink_t st_nlink;
uid_t st_uid;
gid_t st_gid;
dev_t st_rdev;
off_t st_size;
timestruc_t st_atim;
timestruc_t st_mtim;
timestruc_t st_ctim;
blksize_t st_blksize;
blkcnt_tst_blocks;
charst_fstype[_ST_FSTYPSZ];
};
struct stat64 {
dev_t st_dev;
ino_t st_ino;
mode_t st_mode;
nlink_t st_nlink;
uid_t st_uid;
gid_t st_gid;
dev_t st_rdev;
off_t st_size;
timestruc_t st_atim;
timestruc_t st_mtim;
timestruc_t st_ctim;
blksize_t st_blksize;
blkcnt_tst_blocks;
charst_fstype[_ST_FSTYPSZ];
};
#else /* _LP64 */
struct stat {
dev_t st_dev;
longst_pad1[3]; /* reserve for dev expansion, */
/* sysid definition */
ino_t st_ino;
mode_t st_mode;
nlink_t st_nlink;
uid_t st_uid;
gid_t st_gid;
dev_t st_rdev;
longst_pad2[2];
off_t st_size;
longst_pad3;/* pad for future off_t expansion */
timestruc_t st_atim;
timestruc_t st_mtim;
timestruc_t st_ctim;
blksize_t st_blksize;
RE: Feature Branch Solaris Build Broken - lib/glob.c errors
Hi Derek, From: Derek Price 1. #include sys/stat.h within glob_.h file. This would be the way to go. You may commit this if you wish. I committed an inclusion immediately before struct stat forward declaration to assure the Solaris stat macro is used but on 2nd reflection the forward declaration is moot. I'm considering it's removal. Any objection on your part? 2. Move #include glob.h below #include sys/stat.h in glob.c file. This is incorrect. The GNULIB convention is to include a module's header immediately following the include of config.h in its associated source file (i.e. glob.c first including config.h then immediately including glob.h) to test the module's interface. Thank you. Regards, 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, This platform's sys/stat.h implementation in this case defines macros for stat, fstat and lstat to be the tokens stat64, fstat64 and lstat64 respectively. My analysis of sys/stat.h relevent section is below. These macro definitions are in effect when struct stat definition is encountered which becomes struct stat64. Line 187 of lib/glob.c redefines stat64 as: # define stat64 stat which causes later struct stat references to be become struct stat64 which becomes struct stat which is an empty forward declaration at best. It seems defining macros for stat, fstat, lstat, stat64, fstat64 and lstat64 on this platform is a risky proposition. Conrad /* * large file compilation environment setup */ #if !defined(_LP64) _FILE_OFFSET_BITS == 64 // This is true #error Die #ifdef __PRAGMA_REDEFINE_EXTNAME // This is false #error Die #pragma redefine_extnamefstat fstat64 #pragma redefine_extnamestatstat64 #if (!defined(_POSIX_C_SOURCE) !defined(_XOPEN_SOURCE)) || \ defined(_XPG4_2) || defined(__EXTENSIONS__) // This is false #error Die #pragma redefine_extnamelstat lstat64 #endif #else /* __PRAGMA_REDEFINE_EXTNAME */ // This is true #error Die #define fstat fstat64 #define statstat64 #if (!defined(_POSIX_C_SOURCE) !defined(_XOPEN_SOURCE)) || \ defined(_XPG4_2) || defined(__EXTENSIONS__) // This is true #error Die #define lstat lstat64 #endif #endif /* __PRAGMA_REDEFINE_EXTNAME */ #endif /* !_LP64 _FILE_OFFSET_BITS == 64 */ ___ 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: Conrad T. Pino [mailto:[EMAIL PROTECTED]
I choose a broken gcc as the likely culprit. I'll run a test and report.
Test program and results are below.
Conrad
/export/home/cvsusr/ccvs/cvs-1.12:$ cat test00.c; gcc -o test00 test00.c; test00
#include stdio.h
#ifdef __PRAGMA_REDEFINE_EXTNAME
#define p0value defined
#else
#define p0value undefined
#endif
#ifdef _PRAGMA_REDEFINE_EXTNAME
#define p1value defined
#else
#define p1value undefined
#endif
#ifdef PRAGMA_REDEFINE_EXTNAME
#define p2value defined
#else
#define p2value undefined
#endif
int main( int argc, char *argv[ ] )
{
printf( __PRAGMA_REDEFINE_EXTNAME is %s\n, p0value );
printf( _PRAGMA_REDEFINE_EXTNAME is %s\n, p1value );
printf( PRAGMA_REDEFINE_EXTNAME is %s\n, p2value );
return 0;
}
__PRAGMA_REDEFINE_EXTNAME is undefined
_PRAGMA_REDEFINE_EXTNAME is undefined
PRAGMA_REDEFINE_EXTNAME is undefined
/export/home/cvsusr/ccvs/cvs-1.12:$
___
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 [mailto:[EMAIL PROTECTED] (For those new to this thread, this is because the Solaris headers #define stat stat64 when the __PRAGMA_REDEFINE_EXTNAME macro is not defined). Why isn't gcc defining this value? According to what I could find on the web, the compiler should define __PRAGMA_REDEFINE_EXTNAME if it supports the redefine_extname pragma, which this compiler apparently does. http://docs.sun.com/app/docs/doc/816-5175/6mbba7f3u?a=view. That compiler costs money. I'm using gcc distribution supplied on the free software CD distrubuted with Solaris i.e. the 2.95.2 version. Why haven't we seen this error before? Is this a common problem on Solaris 10? Is this problem true of any gcc on any Solaris? Is it specific to your setup? What happens if you use a native Soalris compiler? Because we've never #define stat ... and #define lstat ... before. I haven't tried another gcc version. Must I and must it be on Solaris? I don't know if it's specific to this setup. What should I test? A native Solaris compiler costs money and I don't have one. A quick google search on __PRAGMA_REDEFINE_EXTNAME Solaris 10 gcc brings up a few discussions of this. The gist of the first few I read is that some people ocassionally end up with broken GCCs which do not properly define this macro, but most GCCs should. The reason for the difference was not apparent in the first several pages I scanned. This looks promising even though I have Solaris 8 Intel Edition. Digging a little deeper, this is even documented in the Linux info manual for gcc: Solaris Pragmas --- For compatibility with the SunPRO compiler, the following pragma is supported. `redefine_extname OLDNAME NEWNAME' This pragma gives the C function OLDNAME the assembler label NEWNAME. The pragma must appear before the function declaration. This pragma is equivalent to the asm labels extension (*note Asm Labels::). The preprocessor defines `__PRAGMA_REDEFINE_EXTNAME' if the pragma is available. Perhaps the problem is in your GCC installation or usage? /export/home/cvsusr/ccvs/cvs-1.12/windows-NT:$ gcc -v Reading specs from /opt/sfw/lib/gcc-lib/i386-pc-solaris2.8/2.95.2/specs gcc version 2.95.2 19991024 (release) Isn't usage controlled by CVS make process or did I misunderstand? I choose a broken gcc as the likely culprit. I'll run a test and report. Regards, 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,
We have the same behavior with gcc 3.3.5 on Debian Linux 2.6.8-2-686 platform.
Conrad
[EMAIL PROTECTED]:~$ cat test00.c; uname -a; gcc -v; gcc -o test00 test00.c;
./test00
#include stdio.h
#ifdef __PRAGMA_REDEFINE_EXTNAME
#define p0value defined
#else
#define p0value undefined
#endif
#ifdef _PRAGMA_REDEFINE_EXTNAME
#define p1value defined
#else
#define p1value undefined
#endif
#ifdef PRAGMA_REDEFINE_EXTNAME
#define p2value defined
#else
#define p2value undefined
#endif
int main( int argc, char *argv[ ] )
{
printf( __PRAGMA_REDEFINE_EXTNAME is %s\n, p0value );
printf( _PRAGMA_REDEFINE_EXTNAME is %s\n, p1value );
printf( PRAGMA_REDEFINE_EXTNAME is %s\n, p2value );
return 0;
}
Linux debzfp 2.6.8-2-686 #1 Mon Jan 24 03:58:38 EST 2005 i686 GNU/Linux
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs
Configured with:
../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang
--prefix=/usr --mandir=/usr/share/man --infodir=/usr/
share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared
--enable-__cxa_atexit --with-system-zlib --enable-nls --witho
ut-included-gettext --enable-clocale=gnu --enable-debug --enable-java-gc=boehm
--enable-java-awt=xlib --enable-objc-gc i486-linux
Thread model: posix
gcc version 3.3.5 (Debian 1:3.3.5-12)
__PRAGMA_REDEFINE_EXTNAME is undefined
_PRAGMA_REDEFINE_EXTNAME is undefined
PRAGMA_REDEFINE_EXTNAME is undefined
[EMAIL PROTECTED]:~$
___
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
Solaris Pragmas
---
For compatibility with the SunPRO compiler, the following pragma is
supported.
`redefine_extname OLDNAME NEWNAME'
This pragma gives the C function OLDNAME the assembler label
NEWNAME. The pragma must appear before the function declaration.
This pragma is equivalent to the asm labels extension (*note Asm
Labels::). The preprocessor defines `__PRAGMA_REDEFINE_EXTNAME'
if the pragma is available.
Perhaps the problem is in your GCC installation or usage?
This link is similar to what you've found:
http://gcc.gnu.org/onlinedocs/gcc-3.3.3/gcc/Solaris-Pragmas.html#Solaris%20Pragmas
but this one is different and possibly later:
http://gcc.gnu.org/onlinedocs/gcc/Symbol_002dRenaming-Pragmas.html#Symbol_002dRenaming-Pragmas
which reads, These pragmas are only available on platforms whose system
headers need them.
and perhaps by implication the corresponding macros are there either.
This raises an interesting question. By adding __PRAGMA_REDEFINE_EXTNAME to
the
command line sys/stat.h did NOT #define stat,fstat,lstat ... since the
issue is
CVS and Solaris are both attempting to #define the same tokens and don't
compilers
quietly ignore #pragma statements they don't understand?
See the test program below which compiles and runs with no errors. If we
believe
the test program the redefine_extname pragma is just not implemented. If so I'm
sorry as I sent us barking up the wrong tree.
Regards,
Ditto,
Derek
Conrad
/export/home/cvsusr/ccvs/cvs-1.12:$ cat test01.c fidofifi.?; rm test01; gcc -o
test01 test01.c fidofifi.c; ./test01
=== test01.c follows ===
#include fidofifi.h
void test0( void )
{
printf( test0 fido is %s\n, fido( ) );
printf( test0 fifi is %s\n, fifi( ) );
}
#pragma redefine_extname fido fifi
#pragma garbage_junk radar run
void test1( void )
{
printf( test1 fido is %s\n, fido( ) );
printf( test1 fifi is %s\n, fifi( ) );
}
int main( int argc, char *argv[ ] )
{
test0( );
test1( );
return 0;
}
=== fidofifi.c follows ===
#include fidofifi.h
char * fido( void ) { return fido; }
=== fidofifi.h follows ===
char * fifi( void ) { return fifi; }
#ifndef _FIDOFIFO_H
#define _FIDOFIFO_H 1
#include stdio.h
extern char * fido( void );
extern char * fifi( void );
#endif
=== test01 output ===
test0 fido is fido
test0 fifi is fifi
test1 fido is fido
test1 fifi is fifi
/export/home/cvsusr/ccvs/cvs-1.12:$
___
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 This should be irrelevant, since all reference to struct stat should be made using the Solaris definition. Our code never attempts to define it and I am fairly certain that the struct stat; line in glob_.h only declares the existance of said structure. [snip] See below. I am more suspicious of the __restrict keyword. restrict should not cause this sort of warning by my understanding of the C99 spec, but is it possible that this is doing something we don't understand on Solaris? Here's the prototype of those function calls: #ifdef __USE_GNU int (*gl_lstat) (__const char *__restrict, struct stat *__restrict); int (*gl_stat) (__const char *__restrict, struct stat *__restrict); #else int (*gl_lstat) (__const char *__restrict, void *__restrict); int (*gl_stat) (__const char *__restrict, void *__restrict); #endif So, I am guessing that the problem is here. ST is definitately a struct stat in all three of the calls your compiler is warning about. We should also be able to assume __USE_GNU is set by the line at the beginning of glob_.h. Even if this wasn't so, by C89 any pointer type should be castable to void *, so the problem should still be with the restrict keyword. No amount of playing with __restrict made any difference. I removed it completely and the warning was identical. Either this platform's struct stat implementation or the compiler's interpretation of same are incompatible with a struct stat; forward declaration. The only way I could eliminate the warnings was to either: 1. #include sys/stat.h within glob_.h file. 2. Move #include glob.h below #include sys/stat.h in glob.c file. The patch below implements the latter. I'll commit it if you approve. Ditto, Regards, Ditto, Derek Conrad /export/home/cvsusr/ccvs/cvs-1.12:$ cvs diff -Nup lib/glob.c Index: lib/glob.c === RCS file: /cvs/ccvs/lib/glob.c,v retrieving revision 1.11 diff -u -p -r1.11 glob.c --- lib/glob.c 20 May 2005 18:39:47 - 1.11 +++ lib/glob.c 21 May 2005 00:48:05 - @@ -20,13 +20,13 @@ # include config.h #endif -#include glob.h - #include errno.h #include sys/types.h #include sys/stat.h #include stddef.h +#include glob.h + /* Outcomment the following line for production quality code. */ /* #define NDEBUG 1 */ #include assert.h ___ 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
Excuse me for perhaps being slow but why is configure choosing to
use lib/glob.h when the platform has /usr/include/glob.h whose
contents follow?
/usr/include:$ cat glob.h
/*
* Copyright (c) 1994 by Sun Microsystems, Inc.
* Copyright 1985, 1992 by Mortice Kern Systems Inc. All rights reserved.
*/
#ifndef _GLOB_H
#define _GLOB_H
#pragma ident @(#)glob.h 1.4 95/03/08 SMI
#include sys/types.h
#ifdef __cplusplus
extern C {
#endif
typedef struct glob_t {
size_t gl_pathc; /* Count of paths matched by pattern */
char**gl_pathv; /* List of matched pathnames */
size_t gl_offs;/* # of slots reserved in gl_pathv */
/* following are internal to the implementation */
char**gl_pathp; /* gl_pathv + gl_offs */
int gl_pathn; /* # of elements allocated */
} glob_t;
/*
* flags argument to glob function.
*/
#define GLOB_ERR0x0001 /* Don't continue on directory error */
#define GLOB_MARK 0x0002 /* Mark directories with trailing / */
#define GLOB_NOSORT 0x0004 /* Don't sort pathnames */
#define GLOB_NOCHECK0x0008 /* Return unquoted arg if no match */
#define GLOB_DOOFFS 0x0010 /* Ignore gl_offs unless set */
#define GLOB_APPEND 0x0020 /* Append to previous glob_t */
#define GLOB_NOESCAPE 0x0040 /* Backslashes do not quote M-chars */
/*
* Error returns from glob
*/
#define GLOB_NOSYS (-4)/* function not supported (XPG4) */
#define GLOB_NOMATCH(-3)/* Pattern does not match */
#define GLOB_NOSPACE(-2)/* Not enough memory */
#define GLOB_ABORTED(-1)/* GLOB_ERR set or errfunc return!=0 */
#if defined(__STDC__)
extern int glob(const char *, int, int(*)(const char *, int), glob_t *);
extern void globfree(glob_t *);
#else
extern int glob();
extern void globfree();
#endif
#ifdef __cplusplus
}
#endif
#endif /* _GLOB_H */
/usr/include:$
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
Feature Branch Solaris Build Broken - lib/glob.c errors
I saw test-results shows Sun Solaris and HP HP-UX builds were broken on the 18-May-2005 test runs. A cross check build on Solaris Intel Edition has this problem: gcc -DHAVE_CONFIG_H -I. -I. -I..-Ino/include -g -O2 -c glob.c glob.c:194: conflicting types for `getlogin_r' /usr/include/unistd.h:850: previous declaration of `getlogin_r' glob.c: In function `rpl_glob': glob.c:577: too many arguments to function `getpwnam_r' glob.c:658: too many arguments to function `getpwnam_r' glob.c:712: warning: passing arg 2 of pointer to function from incompatible pointer type glob.c: In function `is_dir_p': glob.c:1059: warning: passing arg 2 of pointer to function from incompatible pointer type glob.c: In function `glob_in_dir': glob.c:1109: warning: passing arg 2 of pointer to function from incompatible pointer type *** Error code 1 make: Fatal error: Command failed for target `glob.o' Current working directory /export/home/cvsusr/ccvs/cvs-1.12/lib *** Error code 1 make: Fatal error: Command failed for target `all' Current working directory /export/home/cvsusr/ccvs/cvs-1.12/lib *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /export/home/cvsusr/ccvs/cvs-1.12 *** Error code 1 make: Fatal error: Command failed for target `all' /export/home/cvsusr/ccvs/cvs-1.12:$ ___ 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
We have an improvement after a recent commit. An old errors was fixed
but a new errors was uncovered:
gcc -DHAVE_CONFIG_H -I. -I. -I..-Ino/include -g -O2 -c glob.c
glob.c: In function `rpl_glob':
glob.c:579: too many arguments to function `getpwnam_r'
glob.c:660: too many arguments to function `getpwnam_r'
glob.c:714: warning: passing arg 2 of pointer to function from incompatible
pointer type
glob.c: In function `is_dir_p':
glob.c:1061: warning: passing arg 2 of pointer to function from incompatible
pointer type
glob.c: In function `glob_in_dir':
glob.c:: warning: passing arg 2 of pointer to function from incompatible
pointer type
*** Error code 1
make: Fatal error: Command failed for target `glob.o'
Current working directory /export/home/cvsusr/ccvs/cvs-1.12/lib
*** Error code 1
make: Fatal error: Command failed for target `all'
Current working directory /export/home/cvsusr/ccvs/cvs-1.12/lib
*** Error code 1
make: Fatal error: Command failed for target `all-recursive'
Current working directory /export/home/cvsusr/ccvs/cvs-1.12
*** Error code 1
make: Fatal error: Command failed for target `all'
/export/home/cvsusr/ccvs/cvs-1.12:$
=== /usr/include/pwd.h content follows =
/usr/include:$ cat pwd.h
/* Copyright (c) 1988 ATT */
/*All Rights Reserved */
/* THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF ATT */
/* The copyright notice above does not evidence any*/
/* actual or intended publication of such source code. */
/*
* Copyright (c) 1996, by Sun Microsystems, Inc.
* All rights reserved.
*/
#ifndef _PWD_H
#define _PWD_H
#pragma ident @(#)pwd.h 1.1996/03/12 SMI /* SVr4.0 1.3.1.9 */
#include sys/feature_tests.h
#include sys/types.h
#if defined(__EXTENSIONS__) || \
(!defined(_POSIX_C_SOURCE) !defined(_XOPEN_SOURCE))
#include stdio.h
#endif
#ifdef __cplusplus
extern C {
#endif
struct passwd {
char*pw_name;
char*pw_passwd;
uid_t pw_uid;
gid_t pw_gid;
char*pw_age;
char*pw_comment;
char*pw_gecos;
char*pw_dir;
char*pw_shell;
};
#if defined(__EXTENSIONS__) || \
(!defined(_POSIX_C_SOURCE) !defined(_XOPEN_SOURCE))
struct comment {
char*c_dept;
char*c_name;
char*c_acct;
char*c_bin;
};
#endif /* defined(__EXTENSIONS__) || (!defined(_POSIX_C_SOURCE) ... */
#if defined(__STDC__)
extern struct passwd *getpwuid(uid_t); /* MT-unsafe */
extern struct passwd *getpwnam(const char *); /* MT-unsafe */
#if defined(__EXTENSIONS__) || \
(!defined(_POSIX_C_SOURCE) !defined(_XOPEN_SOURCE))
extern struct passwd *getpwent_r(struct passwd *, char *, int);
extern struct passwd *fgetpwent_r(FILE *, struct passwd *, char *, int);
extern struct passwd *fgetpwent(FILE *);/* MT-unsafe */
extern int putpwent(const struct passwd *, FILE *);
#endif /* defined(__EXTENSIONS__) || !defined(_POSIX_C_SOURCE) ... */
#if defined(__EXTENSIONS__) || \
(!defined(_POSIX_C_SOURCE) !defined(_XOPEN_SOURCE)) || \
defined(_XPG4_2)
extern void endpwent(void);
extern struct passwd *getpwent(void); /* MT-unsafe */
extern void setpwent(void);
#endif /* defined(__EXTENSIONS__) || (!defined(_POSIX_C_SOURCE) ... */
#else /* (__STDC__) */
extern struct passwd *getpwuid(); /* MT-unsafe */
extern struct passwd *getpwnam(); /* MT-unsafe */
#if defined(__EXTENSIONS__) || \
(!defined(_POSIX_C_SOURCE) !defined(_XOPEN_SOURCE))
extern struct passwd *getpwent_r();
extern struct passwd *fgetpwent_r();
extern struct passwd *fgetpwent(); /* MT-unsafe */
extern int putpwent();
#endif /* defined(__EXTENSIONS__) || (!defined(_POSIX_C_SOURCE) ... */
#if defined(__EXTENSIONS__) || \
(!defined(_POSIX_C_SOURCE) !defined(_XOPEN_SOURCE)) || \
defined(_XPG4_2)
extern void endpwent();
extern struct passwd *getpwent(); /* MT-unsafe */
extern void setpwent();
#endif /* defined(__EXTENSIONS__) || (!defined(_POSIX_C_SOURCE) ... */
#endif /* (__STDC__) */
/*
* getpwuid_r() getpwnam_r() prototypes are defined here.
*/
/*
* Previous releases of Solaris, starting at 2.3, provided definitions of
* various functions as specified in POSIX.1c, Draft 6. For some of these
* functions, the final POSIX 1003.1c standard had a different number of
* arguments and return values.
*
* The following segment of this header provides support for the standard
* interfaces while supporting applications written under earlier
* releases. The application defines appropriate values of the feature
* test macros _POSIX_C_SOURCE and _POSIX_PTHREAD_SEMANTICS to indicate
* whether it was written to expect the Draft 6 or standard versions of
* these interfaces, before including this header. This header then
* provides a mapping from the source version of the interface to an
* appropriate
RE: Feature Branch Solaris Build Broken - lib/glob.c errors
From: Derek Price [mailto:[EMAIL PROTECTED]
I think I just checked in fixes for both Solaris compile problems, this
one and one with getpwnam_r. Could you let me know if they work? I
have no way to test here.
The compile completes but we have warnings (see below). Problem may
be struct stat definition and I've include this platform's definition.
Regards,
Ditto,
Derek
Conrad
719: ? ((*pglob-gl_stat) (dirname, st) == 0
1066: ? (*pglob-gl_stat) (fullname, st) == 0 S_ISDIR (st.st_mode)
1116: ? (*pglob-gl_stat) (fullname, st)
gcc -DHAVE_CONFIG_H -I. -I. -I..-Ino/include -g -O2 -c glob.c
glob.c: In function `rpl_glob':
glob.c:719: warning: passing arg 2 of pointer to function from incompatible
pointer type
glob.c: In function `is_dir_p':
glob.c:1066: warning: passing arg 2 of pointer to function from incompatible
pointer type
glob.c: In function `glob_in_dir':
glob.c:1116: warning: passing arg 2 of pointer to function from incompatible
pointer type
rm -f libcvs.a
ar cru libcvs.a sighandle.o allocsa.o basename.o stripslash.o getnline.o
xalloc-die.o xgetcwd.o xgethostname.o xreadlink.o
save-cwd.o lstat.o mktime.o strftime.o chdir-long.o mempcpy.o openat.o
memrchr.o closeout.o dirname.o exitfail.o getcwd.o getdate.o
getline.o getndelim2.o getopt.o getopt1.o getpass.o gettime.o md5.o
pagealign_alloc.o quotearg.o regex.o rpmatch.o setenv.o
unsetenv.o dup-safer.o fd-safer.o vasnprintf.o printf-args.o printf-parse.o
asnprintf.o vasprintf.o asprintf.o xmalloc.o yesno.o
glob.o
ranlib libcvs.a
=== /usr/include/sys/stat.h follows ===
/usr/include:$ cat sys/stat.h
/*
* Copyright (c) 1995-1999 by Sun Microsystems, Inc.
* All rights reserved.
*/
/* Copyright (c) 1990, 1991 UNIX System Laboratories, Inc. */
/* Copyright (c) 1984, 1986, 1987, 1988, 1989, 1990 ATT */
/* All Rights Reserved */
/* THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF */
/* UNIX System Laboratories, Inc. */
/* The copyright notice above does not evidence any*/
/* actual or intended publication of such source code. */
#ifndef _SYS_STAT_H
#define _SYS_STAT_H
#pragma ident @(#)stat.h 1.2 99/05/19 SMI
#include sys/feature_tests.h
#include sys/types.h
#ifdef __cplusplus
extern C {
#endif
/*
* The implementation specific header sys/time_impl.h includes a
* definition for timestruc_t needed by the stat structure. However,
* including either time.h, which includes sys/time_impl.h, or
* including sys/time_impl.h directly will break both X/Open and
* POSIX namespace. Preceeding tag, structure, and structure member
* names with underscores eliminates the namespace breakage and at the
* same time, with unique type names, eliminates the possibility of
* timespec_t or timestruct_t naming conflicts that could otherwise
* result based on the order of inclusion of sys/stat.h and
* sys/time.h. The header sys/time_std_impl.h contains the
* standards namespace safe versions of these definitions.
*/
#if !defined(_XOPEN_SOURCE) !defined(_POSIX_C_SOURCE) || \
defined(__EXTENSIONS__)
#include sys/time_impl.h
#else
#include sys/time_std_impl.h
#endif /* !defined(_XOPEN_SOURCE) !defined(_POSIX_C_SOURCE) || ... */
#define _ST_FSTYPSZ 16 /* array size for file system type name */
/*
* stat structure, used by stat(2) and fstat(2)
*/
#if defined(_KERNEL)
/* Old SVID stat struct (SVR3.x) */
struct o_stat {
o_dev_t st_dev;
o_ino_t st_ino;
o_mode_tst_mode;
o_nlink_t st_nlink;
o_uid_t st_uid;
o_gid_t st_gid;
o_dev_t st_rdev;
off32_t st_size;
time32_tst_atime;
time32_tst_mtime;
time32_tst_ctime;
};
/* Expanded stat structure */
#if defined(_LP64)
struct stat {
dev_t st_dev;
ino_t st_ino;
mode_t st_mode;
nlink_t st_nlink;
uid_t st_uid;
gid_t st_gid;
dev_t st_rdev;
off_t st_size;
timestruc_t st_atim;
timestruc_t st_mtim;
timestruc_t st_ctim;
blksize_t st_blksize;
blkcnt_tst_blocks;
charst_fstype[_ST_FSTYPSZ];
};
struct stat64 {
dev_t st_dev;
ino_t st_ino;
mode_t st_mode;
nlink_t st_nlink;
uid_t st_uid;
gid_t st_gid;
dev_t st_rdev;
off_t st_size;
timestruc_t st_atim;
timestruc_t st_mtim;
timestruc_t st_ctim;
blksize_t st_blksize;
blkcnt_tst_blocks;
charst_fstype[_ST_FSTYPSZ];
};
#else /* _LP64 */
struct stat {
CVS Stable - checkout alias module exclusion failure with -d option
Hi All, I'm seeking a quick answer from whatever you might know at the moment. If in depth research is needed I plan to follow through with it. Using a version 1.11.20 client with a 1.11.17 server I see an alias module directory exclusion fail when check out is used with -d option. The CVSROOT=:pserver:[EMAIL PROTECTED]:/cvs and the cvs login password is empty. The module definitions are: ACE_wrappers ACE_wrappers-repository ACE -a!ACE_wrappers-repository/TAO ACE_wrappers-repository CAUTION the ACE_wrappers working directory is BIG i.e. 99.8 MB 22,352 files 3,745 directories. The command: cvs -z9 co ACE_wrappers creates directory ACE_wrappers and ACE_wrappers/TAO which is the expected result. The command: cvs -z9 co ACE creates directory ACE_wrappers-repository but NO ACE_wrappers-repository/TAO which is the expected result. The command: cvs -z9 co -d ACE ACE creates directory ACE and ACE/TAO where ACE/TAO is an unexpected result. Is this a previously known or previously fixed bug? Thanks in advance, Conrad Pino ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: Feature Branch Windows Build Broken - New GNULIB glob module
The previous patch to lib/libcvs.dsp doesn't contain fix for the Win32 Release configuration so please don't commit this patch. I have a corrected patch which I plan to commit if that's what is indicated and will supply it if requested but haven't done so because it adds nothing to the debugging process. ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Feature Branch Windows Build Broken - New GNULIB glob module
The following patch lets me get this far in the Windows IDE build: Configuration: libcvs - Win32 Debug Compiling... glob.c H:\Conrad\Projects\cvs-1.12\lib\glob.c(253) : warning C4028: formal parameter 1 different from declaration H:\Conrad\Projects\cvs-1.12\lib\glob.c(253) : warning C4028: formal parameter 4 different from declaration H:\Conrad\Projects\cvs-1.12\lib\glob.c(668) : warning C4090: 'function' : different 'const' qualifiers H:\Conrad\Projects\cvs-1.12\lib\glob.c(668) : warning C4024: 'getpwnam' : different types for formal and actual parameter 1 H:\Conrad\Projects\cvs-1.12\lib\glob.c(739) : warning C4013: 'glob_pattern_p' undefined; assuming extern returning int H:\Conrad\Projects\cvs-1.12\lib\glob.c(334) : fatal error C1600: unsupported data type Error executing cl.exe. cvs.exe - 1 error(s), 5 warning(s) === The following patches do the following: 1. Add WIN32 conditional #defines to lib/glob_.h to hide compile errors. 2. Modify lib/libcvs.dsp to make lib/glob.h file from lib/glob_.h file. 3. Modify Modify lib/libcvs.dsp to build lib/glob.c which is where the compile is failing after my hacks to lib/glob_.h file. === Index: lib/glob_.h === RCS file: /cvs/ccvs/lib/glob_.h,v retrieving revision 1.5 diff -u -p -r1.5 glob_.h --- lib/glob_.h 15 May 2005 16:44:04 - 1.5 +++ lib/glob_.h 17 May 2005 04:18:51 - @@ -19,6 +19,12 @@ #ifndef_GLOB_H #define_GLOB_H 1 +#ifdef WIN32 +#define __BEGIN_DECLS +#define __END_DECLS +#define __const const +#endif + #ifdef _LIBC # include sys/cdefs.h #else Index: lib/libcvs.dsp === RCS file: /cvs/ccvs/lib/libcvs.dsp,v retrieving revision 1.22 diff -u -p -r1.22 libcvs.dsp --- lib/libcvs.dsp 8 May 2005 07:10:06 - 1.22 +++ lib/libcvs.dsp 17 May 2005 04:18:51 - @@ -157,6 +157,10 @@ SOURCE=.\gettime.c # End Source File # Begin Source File +SOURCE=.\glob.c +# End Source File +# Begin Source File + SOURCE=.\md5.c # End Source File # Begin Source File @@ -418,6 +422,25 @@ SOURCE=.\gettext.h # End Source File # Begin Source File +SOURCE=.\glob_.h + +!IF $(CFG) == libcvs - Win32 Release + +!ELSEIF $(CFG) == libcvs - Win32 Debug + +# Begin Custom Build +InputPath=.\glob_.h + +.\glob.h : $(SOURCE) $(INTDIR) $(OUTDIR) + copy .\glob_.h .\glob.h + +# End Custom Build + +!ENDIF + +# End Source File +# Begin Source File + SOURCE=.\md5.h # End Source File # Begin Source File @@ -482,11 +505,11 @@ SOURCE=.\timespec.h # End Source File # Begin Source File -SOURCE=..\windows-NT\unistd.h +SOURCE=.\unistd-safer.h # End Source File # Begin Source File -SOURCE=.\unistd-safer.h +SOURCE=..\windows-NT\unistd.h # End Source File # Begin Source File ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: Feature Branch Windows Build Broken - New GNULIB glob module
Hi Derek,
From: Derek Price [mailto:[EMAIL PROTECTED]
I'm going to suggest something a little more general to the GNULIB
maintainers:
#ifndef __BEGIN_DECLS
# define __BEGIN_DECLS
#endif
#ifndef __END_DECLS
# define __END_DECLS
#endif
#ifndef __const
# define __const const
#endif
In general I agree the above is better.
If __const is a keyword rather than a macro then it won't work but I
can't say for sure what __const is in this context.
I won't comment on the Windows build stuff - it sounds like you are
mirroring what the UNIX build is doing, but otherwise I prefer to stay
out of it.
I saw you're involved with Paul Eggert on a New GNULIB module topic
and assumed we had done another GNULib import which has often broken
the Windows build.
I have my nose buried in another project. My patch is a blind guess
since I didn't look at the UNIX build to see what is going on there.
Your comments lead me to believe I made a lucky guess using glob_.h
and compiling glob.c in the libcvs build.
I've come up with another patch set that seems to solve the situation.
I'd appreciate your input on the revised lib/glob_.h file portion.
The patched file so far are:
Index: lib/glob_.h
Index: lib/libcvs.dsp
Index: windows-NT/pwd.c
Index: windows-NT/pwd.h
I'm willing to commit the Windows build and windows-NT/pwd.? files.
What's your preference on who sends glob_.h patch to GNULib team?
Derek
Conrad
===
Configuration: libcvs - Win32 Debug
Compiling...
glob.c
Creating library...
Configuration: libdiff - Win32 Debug
Creating library...
Configuration: cvsnt - Win32 Debug
Compiling...
find_names.c
H:\Conrad\Projects\cvs-1.12\src\find_names.c(338) : warning C4018: '' :
signed/unsigned mismatch
Linking...
LINK : LNK6004: .\WinDebug\cvs.exe not found or not built by the last
incremental link; performing full link
cvs.exe - 0 error(s), 120 warning(s)
===
Index: lib/glob_.h
===
RCS file: /cvs/ccvs/lib/glob_.h,v
retrieving revision 1.5
diff -u -p -r1.5 glob_.h
--- lib/glob_.h 15 May 2005 16:44:04 - 1.5
+++ lib/glob_.h 17 May 2005 16:15:56 -
@@ -19,6 +19,19 @@
#ifndef_GLOB_H
#define_GLOB_H 1
+#ifndef __BEGIN_DECLS
+# define __BEGIN_DECLS
+#endif
+#ifndef __END_DECLS
+# define __END_DECLS
+#endif
+#ifndef __const
+# define __const const
+#endif
+#ifndef __restrict
+# define __restrict
+#endif
+
#ifdef _LIBC
# include sys/cdefs.h
#else
@@ -204,7 +217,7 @@ extern void globfree64 (glob64_t *__pglo
#endif
-#ifdef __USE_GNU
+#if defined __USE_GNU || !defined _LIBC
/* Return nonzero if PATTERN contains any metacharacters.
Metacharacters can be quoted with backslashes if QUOTE is nonzero.
Index: lib/libcvs.dsp
===
RCS file: /cvs/ccvs/lib/libcvs.dsp,v
retrieving revision 1.22
diff -u -p -r1.22 libcvs.dsp
--- lib/libcvs.dsp 8 May 2005 07:10:06 - 1.22
+++ lib/libcvs.dsp 17 May 2005 16:15:56 -
@@ -157,10 +157,18 @@ SOURCE=.\gettime.c
# End Source File
# Begin Source File
+SOURCE=.\glob.c
+# End Source File
+# Begin Source File
+
SOURCE=.\md5.c
# End Source File
# Begin Source File
+SOURCE=.\mempcpy.c
+# End Source File
+# Begin Source File
+
SOURCE=.\pagealign_alloc.c
# End Source File
# Begin Source File
@@ -418,6 +426,33 @@ SOURCE=.\gettext.h
# End Source File
# Begin Source File
+SOURCE=.\glob_.h
+
+!IF $(CFG) == libcvs - Win32 Release
+
+# Begin Custom Build
+InputPath=.\glob_.h
+
+.\glob.h : $(SOURCE) $(INTDIR) $(OUTDIR)
+ copy .\glob_.h .\glob.h
+
+# End Custom Build
+
+!ELSEIF $(CFG) == libcvs - Win32 Debug
+
+# Begin Custom Build
+InputPath=.\glob_.h
+
+.\glob.h : $(SOURCE) $(INTDIR) $(OUTDIR)
+ copy .\glob_.h .\glob.h
+
+# End Custom Build
+
+!ENDIF
+
+# End Source File
+# Begin Source File
+
SOURCE=.\md5.h
# End Source File
# Begin Source File
@@ -482,11 +517,11 @@ SOURCE=.\timespec.h
# End Source File
# Begin Source File
-SOURCE=..\windows-NT\unistd.h
+SOURCE=.\unistd-safer.h
# End Source File
# Begin Source File
-SOURCE=.\unistd-safer.h
+SOURCE=..\windows-NT\unistd.h
# End Source File
# Begin Source File
Index: windows-NT/pwd.c
===
RCS file: /cvs/ccvs/windows-NT/pwd.c,v
retrieving revision 1.7
diff -u -p -r1.7 pwd.c
--- windows-NT/pwd.c15 May 2004 17:32:22 - 1.7
+++ windows-NT/pwd.c17 May 2005 16:15:56 -
@@ -63,7 +63,7 @@ getpwuid (int uid)
}
struct passwd *
-getpwnam (char *name)
+getpwnam (const char *name)
{
return (struct passwd *) 0;
}
@@ -79,7 +79,7 @@ getgrgid (int uid)
}
RE: Feature Branch Windows Build Broken - New GNULIB glob module
Hi Derek, From: Derek Price [mailto:[EMAIL PROTECTED] Well, basically. I created the glob module myself and added it to CVS and Paul has been reviewing it and I've been correcting it in ways to make it compatible with GNULIB GLIBC. Cool. Another budding published author in our midst. :) I can't comment on how lucky you were, but you did arrive at the correct solution. :) Thank you much appreciated. I'm willing to commit the Windows build and windows-NT/pwd.? files. What's your preference on who sends glob_.h patch to GNULib team? I'll do it. It should slide into my ongoing discussion with Paul about this new module easily enough. +#ifndef __restrict +# define __restrict +#endif This is not correct. It should be #ifndef __restrict # define __restrict restrict #endif If the restrict keyword is not supported by MSVC, then in windows-NT/config.h.in.in, restrict should be defined to some variation of __restrict, __restrict__, _Restrict, or empty. I updated with the recent commit of the glob module and we have a new warning on line 1184 of lib/glob.c file (see below) and the __restrict change made looks fine. The rest of your patch looks fine. OK, I'll have it committed fairly soon. Regards, Ditto, Derek Conrad == Configuration: libcvs - Win32 Debug Performing Custom Build Step on .\glob_.h 1 file(s) copied. Compiling... glob.c h:\conrad\projects\cvs-1.12\lib\glob.c(1187) : warning C4133: ':' : incompatible types - from 'struct direct *' to 'struct dirent *' h:\conrad\projects\cvs-1.12\lib\glob.c(1187) : warning C4133: 'initializing' : incompatible types - from 'struct dirent *' to 'struct direct *' Creating library... Configuration: libdiff - Win32 Debug Creating library... Configuration: cvsnt - Win32 Debug Compiling... find_names.c H:\Conrad\Projects\cvs-1.12\src\find_names.c(338) : warning C4018: '' : signed/unsigned mismatch Linking... LINK : LNK6004: .\WinDebug\cvs.exe not found or not built by the last incremental link; performing full link cvs.exe - 0 error(s), 122 warning(s) == ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: Build CVS (TRUNK) failed.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Mark, From: Mark D. Baushke Sent: Sunday, May 08, 2005 13:48 lib\unistd-safer.h should be what gets used. It was added via a GNULIB update, so it should be there. Last night's test results build worked as did mine this morning. Microsoft Visual C (MVC) has a different opinion for *.dep and *.mak file content. Unless there's something I'm unaware of I plan to commit the following patch tomorrow. Conrad Index: cvsnt.dep === RCS file: /cvs/ccvs/cvsnt.dep,v retrieving revision 1.32 diff -u -p -r1.32 cvsnt.dep - --- cvsnt.dep 8 Mar 2005 05:19:52 - 1.32 +++ cvsnt.dep 9 May 2005 17:59:46 - @@ -3,9 +3,7 @@ .\src\add.c : \ .\lib\dirname.h\ .\lib\exit.h\ - - .\lib\fnmatch.h\ .\lib\getdate.h\ - - .\lib\getopt.h\ .\lib\gettext.h\ .\lib\pathmax.h\ .\lib\regex.h\ @@ -42,9 +40,7 @@ .\src\admin.c : \ .\lib\dirname.h\ .\lib\exit.h\ - - .\lib\fnmatch.h\ .\lib\getdate.h\ - - .\lib\getopt.h\ .\lib\gettext.h\ .\lib\pathmax.h\ .\lib\regex.h\ @@ -79,9 +75,7 @@ .\src\annotate.c : \ .\lib\dirname.h\ .\lib\exit.h\ - - .\lib\fnmatch.h\ .\lib\getdate.h\ - - .\lib\getopt.h\ .\lib\gettext.h\ .\lib\pathmax.h\ .\lib\regex.h\ @@ -116,9 +110,7 @@ .\src\buffer.c : \ .\lib\dirname.h\ .\lib\exit.h\ - - .\lib\fnmatch.h\ .\lib\getdate.h\ - - .\lib\getopt.h\ .\lib\getpagesize.h\ .\lib\gettext.h\ .\lib\pagealign_alloc.h\ @@ -155,9 +147,7 @@ .\src\checkin.c : \ .\lib\dirname.h\ .\lib\exit.h\ - - .\lib\fnmatch.h\ .\lib\getdate.h\ - - .\lib\getopt.h\ .\lib\gettext.h\ .\lib\pathmax.h\ .\lib\regex.h\ @@ -194,9 +184,7 @@ .\src\checkout.c : \ .\lib\dirname.h\ .\lib\exit.h\ - - .\lib\fnmatch.h\ .\lib\getdate.h\ - - .\lib\getopt.h\ .\lib\gettext.h\ .\lib\pathmax.h\ .\lib\regex.h\ @@ -231,9 +219,7 @@ .\src\classify.c : \ .\lib\dirname.h\ .\lib\exit.h\ - - .\lib\fnmatch.h\ .\lib\getdate.h\ - - .\lib\getopt.h\ .\lib\gettext.h\ .\lib\pathmax.h\ .\lib\regex.h\ @@ -268,10 +254,8 @@ .\src\client.c : \ .\lib\dirname.h\ .\lib\exit.h\ - - .\lib\fnmatch.h\ .\lib\getdate.h\ .\lib\getline.h\ - - .\lib\getopt.h\ .\lib\getpagesize.h\ .\lib\gettext.h\ .\lib\md5.h\ @@ -313,10 +297,8 @@ .\src\commit.c : \ .\lib\dirname.h\ .\lib\exit.h\ - - .\lib\fnmatch.h\ .\lib\getdate.h\ .\lib\getline.h\ - - .\lib\getopt.h\ .\lib\gettext.h\ .\lib\pathmax.h\ .\lib\regex.h\ @@ -354,9 +336,7 @@ .\src\create_adm.c : \ .\lib\dirname.h\ .\lib\exit.h\ - - .\lib\fnmatch.h\ .\lib\getdate.h\ - - .\lib\getopt.h\ .\lib\gettext.h\ .\lib\pathmax.h\ .\lib\regex.h\ @@ -391,10 +371,8 @@ .\src\cvsrc.c : \ .\lib\dirname.h\ .\lib\exit.h\ - - .\lib\fnmatch.h\ .\lib\getdate.h\ .\lib\getline.h\ - - .\lib\getopt.h\ .\lib\gettext.h\ .\lib\pathmax.h\ .\lib\regex.h\ @@ -429,9 +407,7 @@ .\src\diff.c : \ .\lib\dirname.h\ .\lib\exit.h\ - - .\lib\fnmatch.h\ .\lib\getdate.h\ - - .\lib\getopt.h\ .\lib\gettext.h\ .\lib\pathmax.h\ .\lib\regex.h\ @@ -466,10 +442,8 @@ .\src\edit.c : \ .\lib\dirname.h\ .\lib\exit.h\ - - .\lib\fnmatch.h\ .\lib\getdate.h\ .\lib\getline.h\ - - .\lib\getopt.h\ .\lib\gettext.h\ .\lib\pathmax.h\ .\lib\regex.h\ @@ -508,10 +482,8 @@ .\src\entries.c : \ .\lib\dirname.h\ .\lib\exit.h\ - - .\lib\fnmatch.h\ .\lib\getdate.h\ .\lib\getline.h\ - - .\lib\getopt.h\ .\lib\gettext.h\ .\lib\pathmax.h\ .\lib\regex.h\ @@ -556,6 +528,7 @@ .\lib\system.h\ .\lib\timespec.h\ .\lib\unlocked-io.h\ + .\lib\vasnprintf.h\ .\lib\wait.h\ .\lib\xalloc.h\ .\lib\xgetcwd.h\ @@ -583,9 +556,7 @@ .\src\exithandle.c : \ .\lib\dirname.h\ .\lib\exit.h\ - - .\lib\fnmatch.h\ .\lib\getdate.h\ - - .\lib\getopt.h\ .\lib\gettext.h\ .\lib\pathmax.h\ .\lib\regex.h\ @@ -620,9 +591,7 @@ .\src\expand_path.c : \ .\lib\dirname.h\ .\lib\exit.h\ - - .\lib\fnmatch.h\ .\lib\getdate.h\ - - .\lib\getopt.h\ .\lib\gettext.h\ .\lib\pathmax.h\ .\lib\regex.h\ @@ -657,10 +626,8 @@ .\src\fileattr.c : \ .\lib\dirname.h\ .\lib\exit.h\ - - .\lib\fnmatch.h\ .\lib\getdate.h\ .\lib\getline.h\ - -
RE: Build CVS (TRUNK) failed.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 From: Mark D. Baushke Given that I 'manually' generated the changes for the MVC files, I have no objections to real versions of those files being committed. You might as well commit the patch today. Done. -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 iQA/AwUBQn/+TrNM28ubzTo9EQI93ACg4nszla2s4eYJUiBuYC3O+5ar4F8AoO0s 4M7eWHTTN0foym0dkC1rDIUp =VA+w -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: Build CVS (TRUNK) failed.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Mark, Sorry to be tuning in late. I'm not always watching the stream. I'm volunteering to fix this one but I need ideas on where to get a unistd-safer.h and my initial though is to hack one together line we did for windows-NT/unistd.h. What are your thoughts? Conrad From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Sunday, May 08, 2005 00:00 Microsoft (R) Program Maintenance Utility Version 1.62.7022 Copyright (C) Microsoft Corp 1988-1997. All rights reserved. cd .\lib NMAKE /A /F .\libcvs.mak CFG=libcvs - Win32 Release Microsoft (R) Program Maintenance Utility Version 1.62.7022 Copyright (C) Microsoft Corp 1988-1997. All rights reserved. if not exist .\WinRel/ mkdir .\WinRel tempfile.bat 1 file(s) copied. tempfile.bat 1 file(s) copied. tempfile.bat 1 file(s) copied. NMAKE : fatal error U1073: don't know how to make '..\windows-NT\unistd-safer.h' Stop. NMAKE : fatal error U1077: 'C:\Program Files\DevStudio\VC\BIN\NMAKE.EXE' : return code '0x2' Stop. -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 iQA/AwUBQn5RbbNM28ubzTo9EQJPeACg2OuC1x1a0KvzYmYw1871NXzsYCEAn0Ue 0ObuURyfC2Noh18GjBes78+f =ivQm -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: MacOS X 10.3.7 Build Problem After CVS CheckOut
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Derek, From: Derek Price [mailto:[EMAIL PROTECTED] I never thought it was worth coming up with a more automated solution, but you're welcome to try. I would argue against changing the name of the executable though, and I'm not sure what else is workable. The configure script could test for the existence of a directory named src/cvs and if true then execute a mkdir build command if build is not already created. That being said, how many shell variations need to be tested before we commit such a fix assuming there are no objections? Cheers, Ditto, Derek Conrad -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 iQA/AwUBQng1o7NM28ubzTo9EQJ4WwCgk0yMbtCgfIihIqdu4SfRVZx6bzcAn3aI 1QX5NKqIyvSn0RQn2k04rwkf =5J85 -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
MacOS X 10.3.7 Build Problem After CVS CheckOut
I'm seeing the same build problem on both stable feature: Titanium:~/projects/cvs-1.12.12 conradtpino$ make make all-recursive Making all in lib make all-am make[3]: Nothing to be done for `all-am'. Making all in zlib make[2]: Nothing to be done for `all'. Making all in diff make[2]: Nothing to be done for `all'. Making all in src rm: cvs: is a directory make[2]: *** [cvs] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Titanium:~/projects/cvs-1.12.12 conradtpino$ The problem occurs because the MacOS file system appears to be case insensitive with respect to file names i.e. both of the following do the same thing: ls CVS ls cvs I'm seeing the error for the first time because I checked out with a revision tag instead of downloading a tar ball. I can work around the problem by using export instead of checkout command. The question becomes: Is it worthwhile fixing the build to deal with case insensitive UNIX file systems? Conrad ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: GNULib save-cwd.c on Windows Visual Studio 6.0
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Jim,
From: Jim Meyering [mailto:[EMAIL PROTECTED]
This is not about Microsoft per se, but simply about
the lack of fchdir (or POSIX support in general) in WOE.
I agree let's not enumerate Microsoft's flaws as we would never
finish. :)
I suppose it's a long shot, but...
is there a way, in WOE/MSVC, to emulate fchdir's behavior?
I think not. My research on http://msdn.microsoft.com site came
up with no hint of a method to translate an open file / directory
handle into a path name.
I.e., given a file descriptor that is the result of opening a
directory, can you obtain an absolute path name of that directory?
Worse, if C:\work is a directory attempts to use the Visual C 6.0
open function with _O_RDONLY argument to open . or C:\work
will both return -1 value i.e. error. Sample program follows.
Conrad
#include stdio.h
#include io.h
#include fcntl.h
static int opendir( char *name )
{
int fd;
fd = open( name, _O_RDONLY );
printf( open %s = %d\n, name, fd );
close( fd );
return fd;
}
int main(int argc, char* argv[])
{
int fd;
printf(Hello World!\n);
fd = opendir( test.txt );
fd = opendir( . );
fd = opendir( C:\\work );
return 0;
}
-BEGIN PGP SIGNATURE-
Version: PGP 7.0.4
iQA/AwUBQi8GwLNM28ubzTo9EQJxHwCg4H3VBV4ftjY6Jau9DuleH/0mvykAoLee
EKxRsykxCHYpu0r1VRvKe6aq
=RI6I
-END PGP SIGNATURE-
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: GNULib save-cwd.c on Windows Visual Studio 6.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jim, From: Jim Meyering [mailto:[EMAIL PROTECTED] Here's a patch that should restore the ability of save-cwd to work on systems without the fchdir function. Would you please see if this is sufficient? If so, I'll check it in to gnulib (with an AC_CHECK_FUNCS(fchdir) in save-cwd.m4). The patch as submitted does not compile. This line fails: return fchdir (cwd-desc); The patch at message end does compile and the build completes. Conrad Index: save-cwd.c === RCS file: /cvs/ccvs/lib/save-cwd.c,v retrieving revision 1.6 diff -u -p -r1.6 save-cwd.c - --- save-cwd.c 1 Mar 2005 18:15:42 - 1.6 +++ save-cwd.c 9 Mar 2005 14:50:43 - @@ -44,6 +44,18 @@ #include chdir-long.h #include xgetcwd.h +/* On systems without the fchdir function (WOE), pretend that open + always returns -1 so that save_cwd resorts to using xgetcwd. + Since chdir_long requires fchdir, use chdir instead. */ +#if !HAVE_FCHDIR +# undef open +# define open(File, Flags) -1 +# undef fchdir +# define fchdir(Fd) ( abort (), -1 ) +# undef chdir_long +# define chdir_long(Dir) chdir (Dir) +#endif + /* Record the location of the current working directory in CWD so that the program may change to other directories and later use restore_cwd to return to the recorded location. This function may allocate -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 iQA/AwUBQi8OqrNM28ubzTo9EQKCQACglWgegbLzUqZdLaxd+HC+ls9Jv7oAn1J5 0z2tXUL54UlQZECFNzsG4PuC =7E/O -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: windows-NT/mkconfig.pl windows-NT/fix-msvc-mak.pl change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Derek, I'm slow to understand the goal. I'm coming to the conclusion what you're trying is eliminate the difference between: *** config.h.in, generated by mkconfig: as opposed to: *** config.h.in, generated by mkconfig.pl: and if that's the case then I believe it's not a Windows or UNIX issue. I propose it's an operation difference issue as follows: The UNIX make process generates intermediates: fix-msvc-mak mkconfig of which mkconfig is used later in the build and fix-msvc-mak is built but not used in the build. Previously I wasn't aware of the existence of the intermediates on UNIX and of course they don't exist on Windows. The commands I ran on both Windows and UNIX are: cd ccvs perl windows-NT/fix-msvc-mak.pl cd windows-NT perl mkconfig.pl cd .. which in the case of mkconfig will generate: *** config.h.in, generated by mkconfig.pl: when run on either Windows and UNIX. I believe no patch is required. I will correct my process now that I understand why the intermediates exist. Conrad -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 iQA/AwUBQi9JjrNM28ubzTo9EQIKhgCglpDGRupS5gwAKZD0wxVqMKdlzA4An2rk Lv3ZH3gShpt7zrOIkbvhB0Vw =sbX4 -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: GNULib save-cwd.c on Windows Visual Studio 6.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jim, From: Jim Meyering [mailto:[EMAIL PROTECTED] Conrad T. Pino [EMAIL PROTECTED] wrote: ... Would you please see if this is sufficient? If so, I'll check it in to gnulib (with an AC_CHECK_FUNCS(fchdir) in save-cwd.m4). The patch as submitted does not compile. This line fails: return fchdir (cwd-desc); The patch at message end does compile and the build completes. Thanks. I've checked that in. I've seen the lib/save-cwd.c change in GULLib CVS on Savannah but I didn't see the AC_CHECK_FUNCS(fchdir) in save-cwd.m4 change. Conrad -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 iQA/AwUBQi+5KrNM28ubzTo9EQLWKwCgp1C8kpucYC92QRaGblHAp5+z0xIAniOF WX8BVodiTSIchNoDxIi4ZwT9 =Nwqu -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: windows-NT/mkconfig.pl windows-NT/fix-msvc-mak.pl change
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Derek,
From: Derek Price [mailto:[EMAIL PROTECTED]
I've attached the diff. Conrad or somebody, would you mind verifying
that after applying this patch (on WOE32, only the two named files will
be relevant)...
Please define the phrase two named files by enumerating the names.
...that you can still run the programs?
Yes I will but I'd appreciate an enumerated definition of the programs
or a list of commands to run specifying which platform (Windows 2000 or
Solar 8 Intel) to use.
... After this change,
the content of these files generated in WOE or on UNIX should look the
same (previously, WOE said generated by 'XXX.pl' where UNIX said
generated by 'xxx').
OK, I'm picking up the goal is run whatever on both Windows and UNIX to
make sure the generated results are identical.
File mkconfig.pl has changes that prevent is from running with PERL
implementation supplied with old MKS Tool Kit I have on Windows 2000.
Error output and MKS PERL version information follow at message end.
I can install a modern PERL binary release which will take some time
but I could report back results in a day or two.
What's you preference (1) fix mkconfig.pl to run with MKS PERL I have
or (2) install a modern PERL binary release?
Thanks,
Ditto,
Derek
Conrad
H:\Conrad\Projects\cvs-1.12\windows-NTperl mkconfig.pl
mv is not exported by the File::Copy module at
C:\MKSToolKit/etc/perl/lib/Exporter.pm line 95
Exporter::export called at C:\MKSToolKit/etc/perl/lib/Exporter.pm line
149
Exporter::import called at mkconfig.pl line 4
main::BEGIN called at C:\MKSToolKit/etc/perl/lib/File/Copy.pm line 0
eval {...} called at C:\MKSToolKit/etc/perl/lib/File/Copy.pm line 0
Can't continue after import errors at mkconfig.pl line 4
BEGIN failed--compilation aborted at mkconfig.pl line 4.
H:\Conrad\Projects\cvs-1.12\windows-NTperl -v
This is perl, version 5.003 with DEBUGGING MULTIPLICITY
built under Windows_NT at Sep 24 1997 00:36:07
+ suidperl security patch
Copyright 1987-1996, Larry Wall
Win32 port Copyright 1996 by Mortice Kern Systems Inc.
MKS version 6.1 build 209
Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5.0 source kit.
H:\Conrad\Projects\cvs-1.12\windows-NT
-BEGIN PGP SIGNATURE-
Version: PGP 7.0.4
iQA/AwUBQi369rNM28ubzTo9EQIHpQCfTD5zOpubbOFMNX/+A90Z2tHoyDEAoO99
lRkHnCub4JB5AFRzXvsOIpJi
=1EEN
-END PGP SIGNATURE-
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
lib/stdint.h intermediate file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The build process on Solaris 8 Intel Edition seems to generate lib/stdint.h as an intermediate build product. Is there any objection to adding stdint.h to the lib/.cvsignore file? -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 iQA/AwUBQi39HbNM28ubzTo9EQLydACfb4/CNDo6/fQTCmhQivqpp6frXvMAoN1x +w0Dp9pVwQKCztiVzs204YnU =exQ5 -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: windows-NT/mkconfig.pl windows-NT/fix-msvc-mak.pl change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Derek, From: Derek Price [mailto:[EMAIL PROTECTED] The two files are listed in the subject line. :) Oops, I need another cup of coffee!! :) First off, the problem cited in your output is not caused by the patch I just sent, but I'll deal with it anyhow. Yes, I was aware of that but since it prevented an immediate run of the process I wanted you to know the basis of the delay. I didn't intend to imply you needed to act and please don't at this time (see below). Secondly, I think I would prefer that you use a more modern Perl release (I've had good luck with the version shipped by ActiveState - the installer is quick easy it doesn't require any external libraries). I'm happy to try a modern PERL. Expect feedback in a day or two. Regards, Ditto, Derek Conrad -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 iQA/AwUBQi4FMrNM28ubzTo9EQK4WwCfbFDSKfEgvkjCcRxmuILe0mZbLCUAniwR eOM6y6eCr3YObD7vtpNIUTxL =0DRc -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
CVS Feature Branch - Windows Build Broken - valloc more
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Derek, Recent changes with various items broke the Windows build beginning with test build on Wed 2-Mar-2005 and all days since. The item broken changed about every other day and src/buffer.c changes related to the removal of valloc is the current stumbling block: - Configuration: cvsnt - Win32 Debug Compiling... buffer.c H:\Conrad\Projects\cvs-1.12\src\buffer.c(67) : warning C4013: 'buf_free_data' undefined; assuming extern returning int H:\Conrad\Projects\cvs-1.12\src\buffer.c(161) : warning C4018: '=' : signed/unsigned mismatch H:\Conrad\Projects\cvs-1.12\src\buffer.c(529) : error C2371: 'buf_free_data' : redefinition; different basic types H:\Conrad\Projects\cvs-1.12\src\buffer.c(1063) : warning C4018: '==' : signed/unsigned mismatch H:\Conrad\Projects\cvs-1.12\src\buffer.c(1120) : warning C4018: '=' : signed/unsigned mismatch H:\Conrad\Projects\cvs-1.12\src\buffer.c(1164) : warning C4018: '=' : signed/unsigned mismatch H:\Conrad\Projects\cvs-1.12\src\buffer.c(1189) : warning C4018: '==' : signed/unsigned mismatch Error executing cl.exe. cvs.exe - 1 error(s), 6 warning(s) The PROXY_SUPPORT macro reference in src/buffer.h controls the buf_free_data function prototype. What's your take on PROXY_SUPPORT macro for Windows? I'm working on fixing the Windows build but I've noted Windows config.h precursors haven't been updated in some time. I'm sure there'll be more questions on other config macros later. Conrad -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 iQA/AwUBQiz/+LNM28ubzTo9EQKyEwCfdtYiz5/Gtp5vlwoBfabTd88IjD4AoN6c gwwuB5YSz32OxTSbeV3ENJan =+ITF -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: CVS Feature Branch - Windows Build Broken - valloc more
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Derek, From: Conrad T. Pino Sent: Monday, March 07, 2005 17:29 The PROXY_SUPPORT macro reference in src/buffer.h controls the buf_free_data function prototype. What's your take on PROXY_SUPPORT macro for Windows? Disregard the above. I committed a fix to src/buffer.h file. I committed fixes to Visual C 6.0 project files for the changes made recently but we have one remaining problem. Windows does not implement fchdir function. I didn't see an implementation in the GNULIB source archive. I'll start a thread with GNULIB project and let's see where that goes. Conrad - Configuration: cvsnt - Win32 Debug Linking... libdiff.lib(save-cwd.obj) : error LNK2001: unresolved external symbol _fchdir .\WinDebug\cvs.exe : fatal error LNK1120: 1 unresolved externals Error executing link.exe. cvs.exe - 2 error(s), 0 warning(s) -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 iQA/AwUBQi1BK7NM28ubzTo9EQIn+wCgl9FZ5u25hYP47f8zWYcs4lLM+JkAoK0d vt+2illy8JU5P++WwcfNMsws =2mho -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
GNULib save-cwd.c on Windows Visual Studio 6.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jim, The CVS project compiles the Windows CVS binary with Microsoft Visual Studio 6.0 which doesn't have a fchdir implementation which is used in save-cwd.c module. The comments say: Some systems lack fchdir altogether: e.g., OS/2, pre-2001 Cygwin, SCO Xenix. Also, SunOS 4 and Irix 5.3 provide the function, yet it doesn't work for partitions on which auditing is enabled. If you're still using an obsolete system with these problems, please send email to the maintainer of this code. Function fchdir is also used in chdir-long.c and openat.c modules which may not be used in Windows build. What would you suggest for this issue? Best regards, Conrad T. Pino The grep fchdir ... and build error outputs follow: File lib\chdir-long.c: 56 cdb_fchdir (struct cd_buf const *cdb) 58return fchdir (cdb-fd); 200 if (cdb_fchdir (cdb) != 0) File lib\openat.c: 39 Simulate it by doing save_cwd/fchdir/open/restore_cwd. 72if (fchdir (fd) != 0) 95 Simulate it by doing save_cwd/fchdir/opendir(.)/restore_cwd. 114 if (fchdir (fd) != 0) 137Simulate it by doing save_cwd/fchdir/(stat|lstat)/restore_cwd. 158 if (fchdir (fd) != 0) File lib\save-cwd.c: 58 So, we prefer to use the open/fchdir approach, but fall back on 61 Some systems lack fchdir altogether: e.g., OS/2, pre-2001 Cygwin, 87 Upon failure, return -1 (errno is set by chdir or fchdir). 94 return fchdir (cwd-desc); - Configuration: cvsnt - Win32 Debug Linking... libdiff.lib(save-cwd.obj) : error LNK2001: unresolved external symbol _fchdir .\WinDebug\cvs.exe : fatal error LNK1120: 1 unresolved externals Error executing link.exe. cvs.exe - 2 error(s), 0 warning(s) -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 iQA/AwUBQi1FBbNM28ubzTo9EQLO3QCg15DJbXoDCR7MkuO9QaHHJ0WR0IsAoOce YbYCRgf5hlXqTTwOnw5E4RXR =F+Nb -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: CVS Feature Branch - Windows Build Broken - run_add_arg, run_piped
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The following patch fixes all build errors.
I don't claim it works and I don't claim it doesn't work.
It's a good guess and I'd appreciate feedback before committing.
Index: windows-NT/run.c
===
RCS file: /cvs/ccvs/windows-NT/run.c,v
retrieving revision 1.18
diff -u -p -r1.18 run.c
- --- windows-NT/run.c 22 Mar 2004 15:37:37 - 1.18
+++ windows-NT/run.c21 Feb 2005 21:35:53 -
@@ -22,11 +22,6 @@
#include io.h
#include fcntl.h
- -static void run_add_arg( const char *s );
- -static void run_init_prog( void );
- -
- -extern char *strtok ();
- -
/*
* To exec a program under CVS, first call run_setup() to setup any initial
* arguments. The options to run_setup are essentially like printf(). The
@@ -72,13 +67,6 @@ run_setup (const char *prog)
free (run_prog);
}
- -void
- -run_arg (s)
- -const char *s;
- -{
- -run_add_arg (s);
- -}
- -
/* Return a malloc'd copy of s, with double quotes around it. */
static char *
quote (const char *s)
@@ -108,7 +96,7 @@ quote (const char *s)
return copy;
}
- -static void
+void
run_add_arg (s)
const char *s;
{
@@ -697,6 +685,15 @@ filter_stream_through_program (oldfd, di
}
+int
+run_piped (int *tofdp, int *fromfdp)
+{
+run_add_arg (NULL);
+return piped_child (run_argv, tofdp, fromfdp);
+}
+
+
+
/* Arrange for the file descriptor FD to not be inherited by child
processes. At the moment, CVS uses this function only on pipes
returned by piped_child, and our implementation of piped_child
-BEGIN PGP SIGNATURE-
Version: PGP 7.0.4
iQA/AwUBQhpV0rNM28ubzTo9EQJtCwCggQQBdckEYxiD59AJv5rFiJN6VG4AoL1S
0Hjqrccd7gIa/IrUfFLLU6RZ
=zCTd
-END PGP SIGNATURE-
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
Windows POSIX
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Derek, New thread started from Frank Hemmer's :ext: with ssh failure on w2k - patch thread. I agree with Frank that Windows select implementation accepts neither pipe nor file descriptors. Microsoft claims POSIX compliance for Windows but IMO it's no where near the level the UNIX world supports. In addition to the select problem, Windows does NOT implement fcntl at all. Where open, read, write, close, etc. are kernel functions in UNIX, the same are C run-time functions in Windows Visual C++ and non-blocking I/O isn't supported at all. I could go with details but the points I want to raise are: 1. CVS does NOT abstract POSIX low level I/O: open, read, write, close, select, etc. 2. Microsoft is unlikely to advance POSIX compliance for Windows to be sufficiently useful. Over the long term we're confronted with providing real POSIX support for Windows OR dropping Windows support. I prefer to avoid the latter. As I see it if we are to continue down the path toward better performance of the current src/buffer.c then we should replace Microsoft's poor implementation with our own. Can you quickly enumerate a list of functions that we need to replace to keep moving forward on the current performance improvement path? Is it sufficient to replace the problematic functions relying on the linker to use our implementation without using a macro such as CVS_OPEN for open? Best regards, Conrad -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 iQA/AwUBQhp4WbNM28ubzTo9EQIkYQCgnofaeW9JueAdGFd7RaNhHa6JI8UAn3cf vmGU3Q2PG1dmY5lUe7ELjhAi =zUOy -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: Windows POSIX
Hi Derek, My Visual C++ 6.0 installation has source for the C Run Time library. File handles returned by open and create are NOT Windows API level file handles. They are an index into arrays of an internal library structure which contains a field for saving the Windows API level file handle. The Windows Socket API says socket handles MAY be used as Windows API level file handles: http://msdn.microsoft.com/library/en-us/winsock/winsock/socket_handles_2.asp Not as definite as I would prefer. To assure POSIX semantics it seems we need to insure file and socket handles exist in a single number space so they can be used together in a select implementation. How does abstracting all CVS I/O calls for files, pipes and sockets sound to you? Conrad ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: :ext: with ssh failure on w2k - patch
Hi Derek, From: Derek Price I don't like this patch. It must be in the wrong direction. I refuse to believe that there is really no way to set non-blocking mode on a file descriptor on Windows. Surely there is a header that could be included to get at the F_GETFL, O_NONBLOCK, F_SETFL macros? Alternatively, surely there is an alternative function (to fcntl) that may have the same effect of setting the nonblock flag on the file? At the Windows 32-bit API level, blocking vs. non-blocking has no real meaning because ALL file handles are non-blocking. All I/O functions have blocking and non-blocking implementations. The developer chooses blocking behavior by choosing the appropriate API function. CVS has problems because it is NOT written to use the Windows 32-bit API. CVS is written to the Windows POSIX layer which is known to be a poor POSIX implementation. I don't claim to understand this issue but if someone can point out the problem code and make a clear statement about the desired behavior that is needed from the Windows API then I'll commit some time to making code suggestions. Cheers, Ditto, Derek Conrad ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
