Discussion:
Windows Build Broken: /ccvs/lib/ getopt.h, getopt_.h, getopt_int.h
Conrad T. Pino
2004-10-07 06:50:53 UTC
Permalink
--------------------Configuration: libcvs - Win32 Debug--------------------
Compiling...
fncase.c
h:\conrad\projects\cvs-1.12\lib\system.h(58) : fatal error C1083: Cannot open include file: 'getopt.h': No such file or directory
getopt.c
h:\conrad\projects\cvs-1.12\lib\getopt.c(79) : fatal error C1083: Cannot open include file: 'getopt.h': No such file or directory
getopt1.c
h:\conrad\projects\cvs-1.12\lib\getopt1.c(27) : fatal error C1083: Cannot open include file: 'getopt.h': No such file or directory
sighandle.c
h:\conrad\projects\cvs-1.12\lib\system.h(58) : fatal error C1083: Cannot open include file: 'getopt.h': No such file or directory
valloc.c
h:\conrad\projects\cvs-1.12\lib\system.h(58) : fatal error C1083: Cannot open include file: 'getopt.h': No such file or directory
Error executing cl.exe.

cvs.exe - 5 error(s), 0 warning(s)
Sent: Wednesday, October 06, 2004 12:25
Subject: CVS update: /ccvs/lib/
User: dprice
Date: 04/10/06 12:24:51
/ccvs/lib/
getopt.h
/ccvs/lib/
getopt_.h, getopt_int.h
/ccvs/lib/
ChangeLog, Makefile.am, Makefile.gnulib, Makefile.in, getopt.c, getopt1.c
* getopt.h: Remove file.
* getopt_.h, getopt_int.h: New files from GNULIB.
* getopt1.c: Update from GNULIB.
Derek Robert Price
2004-10-07 13:32:49 UTC
Permalink
getopt.h needs to be created from getopt_.h when it doesn't exist on a
system, as I presume it doesn't on Windows. The procedure should be
the same as for fnmatch_.h , alloca_.h, and the others.

I tried to define what I thought I could guess at accurately, but
there are a few definitions missing on Windows now that probably
aren't vital but could speed things up:

$ ./mkconfig -q ../config.h.in ./config.h.in ./config.h.in.in
./config.h.in.footer
../config.h.in line 468 has #undef HAVE_STDIO_EXT_H not found in
./config.h.in.in
../config.h.in line 474 has #undef HAVE_STRCASECMP not found in
./config.h.in.in../config.h.in line 495 has #undef HAVE_STRNCASECMP
not found in ./config.h.in.in
../config.h.in line 629 has #undef HAVE_WMEMCHR not found in
./config.h.in.in
../config.h.in line 632 has #undef HAVE_WMEMCPY not found in
./config.h.in.in
../config.h.in line 992 has #undef optarg not found in ./config.h.in.in
../config.h.in line 995 has #undef optind not found in ./config.h.in.in
../config.h.in line 998 has #undef optopt not found in ./config.h.in.in

I'm guessing HAVE_STDIO_EXT_H won't exist and needs to be defined to
0, but I didn't really know. HAVE_STRCASECMP and the other HAVE_s, I
have no idea about. I have no idea about optarg, optind, and optopt
either. Those need to be defined to rpl_optarg, rpl_optind, and
rpl_optopt, respectively, if they don't exist on Windows. These
globals are normally exported as part of the getopt() function. I
gathered that Windows wouldn't have a GNU compatible getopt(), but
didn't know if it had some form of getopt() which did export these
variables.

Cheers,

Derek
Post by Conrad T. Pino
--------------------Configuration: libcvs - Win32
Debug--------------------
Post by Conrad T. Pino
Compiling...
fncase.c
Cannot open include file: 'getopt.h': No such file or directory
Post by Conrad T. Pino
getopt.c
Cannot open include file: 'getopt.h': No such file or directory
Post by Conrad T. Pino
getopt1.c
Cannot open include file: 'getopt.h': No such file or directory
Post by Conrad T. Pino
sighandle.c
Cannot open include file: 'getopt.h': No such file or directory
Post by Conrad T. Pino
valloc.c
Cannot open include file: 'getopt.h': No such file or directory
Post by Conrad T. Pino
Error executing cl.exe.
cvs.exe - 5 error(s), 0 warning(s)
Sent: Wednesday, October 06, 2004 12:25
Subject: CVS update: /ccvs/lib/
User: dprice
Date: 04/10/06 12:24:51
/ccvs/lib/
getopt.h
/ccvs/lib/
getopt_.h, getopt_int.h
/ccvs/lib/
ChangeLog, Makefile.am, Makefile.gnulib, Makefile.in, getopt.c, getopt1.c
* getopt.h: Remove file.
* getopt_.h, getopt_int.h: New files from GNULIB.
* getopt1.c: Update from GNULIB.
- --
*8^)

Email: ***@ximbiot.com

Get CVS support at <http://ximbiot.com>!
Conrad T. Pino
2004-10-09 17:05:50 UTC
Permalink
Hi Derek,
From: Derek Robert Price
Sent: Thursday, October 07, 2004 06:33
getopt.h needs to be created from getopt_.h when it doesn't exist on a
system, as I presume it doesn't on Windows. The procedure should be
the same as for fnmatch_.h , alloca_.h, and the others.
I committed a fix for the above at 17:47:11 on 7-Oct-2004.
I tried to define what I thought I could guess at accurately, but
there are a few definitions missing on Windows now that probably
$ ./mkconfig -q ../config.h.in ./config.h.in ./config.h.in.in
./config.h.in.footer
../config.h.in line 468 has #undef HAVE_STDIO_EXT_H not found in
./config.h.in.in
../config.h.in line 474 has #undef HAVE_STRCASECMP not found in
./config.h.in.in../config.h.in line 495 has #undef HAVE_STRNCASECMP
not found in ./config.h.in.in
../config.h.in line 629 has #undef HAVE_WMEMCHR not found in
./config.h.in.in
../config.h.in line 632 has #undef HAVE_WMEMCPY not found in
./config.h.in.in
../config.h.in line 992 has #undef optarg not found in ./config.h.in.in
../config.h.in line 995 has #undef optind not found in ./config.h.in.in
../config.h.in line 998 has #undef optopt not found in ./config.h.in.in
I'm guessing HAVE_STDIO_EXT_H won't exist and needs to be defined to
0, but I didn't really know. HAVE_STRCASECMP and the other HAVE_s, I
have no idea about. I have no idea about optarg, optind, and optopt
either. Those need to be defined to rpl_optarg, rpl_optind, and
rpl_optopt, respectively, if they don't exist on Windows. These
globals are normally exported as part of the getopt() function. I
gathered that Windows wouldn't have a GNU compatible getopt(), but
didn't know if it had some form of getopt() which did export these
variables.
The Windows Build completes without any of the above. I don't claim to
know or imply that means anything about the function of the executable.

I really can't claim authorative knowledge about Windows having a GNU
compatible "getopt" function. I coded a test program with a "getopt"
call with no arguments and the linker was unable to resolve it.

The patch at the end of this message quit the "mkconfig.pl" warnings
without acutally doing anything. It's a crude starting point and I'd
like to know if you think it's worthwhile committing.

I'm open to other suggestions regarding lines of investigation leading
towards a better resolution.
Cheers,
Derek
Conrad

Index: config.h.in.in
===================================================================
RCS file: /cvs/ccvs/windows-NT/config.h.in.in,v
retrieving revision 1.12
diff -u -p -r1.12 config.h.in.in
--- config.h.in.in 6 Oct 2004 23:57:51 -0000 1.12
+++ config.h.in.in 9 Oct 2004 16:48:51 -0000
@@ -462,9 +462,15 @@
uintmax_t. */
#undef HAVE_STDINT_H_WITH_UINTMAX

+/* Define to 1 if you have the <stdio_ext.h> header file. */
+#undef HAVE_STDIO_EXT_H
+
/* Define to 1 if you have the <stdlib.h> header file. */
#define HAVE_STDLIB_H 1

+/* Define to 1 if you have the `strcasecmp' function. */
+#undef HAVE_STRCASECMP
+
/* Define if you have strchr (always for CVS). */
#undef HAVE_STRCHR

@@ -483,6 +489,9 @@
/* Define to 1 if you have the <string.h> header file. */
#define HAVE_STRING_H 1

+/* Define to 1 if you have the `strncasecmp' function. */
+#undef HAVE_STRNCASECMP
+
/* Define to 1 if you have the `strstr' function. */
#undef HAVE_STRSTR

@@ -614,6 +623,12 @@
/* Define if you have the 'wint_t' type. */
#undef HAVE_WINT_T

+/* Define to 1 if you have the `wmemchr' function. */
+#undef HAVE_WMEMCHR
+
+/* Define to 1 if you have the `wmemcpy' function. */
+#undef HAVE_WMEMCPY
+
/* Define to 1 if you have the `wmempcpy' function. */
#undef HAVE_WMEMPCPY

@@ -974,6 +989,15 @@
/* Define to rpl_nanosleep if the replacement function should be used. */
#undef nanosleep

+/* Define to rpl_optarg if the replacement variable should be used. */
+#undef optarg
+
+/* Define to rpl_optind if the replacement variable should be used. */
+#undef optind
+
+/* Define to rpl_optopt if the replacement variable should be used. */
+#undef optopt
+
/* Define to `int' if <sys/types.h> does not define. */
#define pid_t int
Derek Robert Price
2004-10-09 20:59:00 UTC
Permalink
Post by Conrad T. Pino
Post by Derek Robert Price
I tried to define what I thought I could guess at accurately, but
there are a few definitions missing on Windows now that probably
$ ./mkconfig -q ../config.h.in ./config.h.in ./config.h.in.in
./config.h.in.footer
../config.h.in line 468 has #undef HAVE_STDIO_EXT_H not found in
./config.h.in.in
../config.h.in line 474 has #undef HAVE_STRCASECMP not found in
./config.h.in.in../config.h.in line 495 has #undef HAVE_STRNCASECMP
not found in ./config.h.in.in
../config.h.in line 629 has #undef HAVE_WMEMCHR not found in
./config.h.in.in
../config.h.in line 632 has #undef HAVE_WMEMCPY not found in
./config.h.in.in
../config.h.in line 992 has #undef optarg not found in ./config.h.in.in
../config.h.in line 995 has #undef optind not found in ./config.h.in.in
../config.h.in line 998 has #undef optopt not found in ./config.h.in.in
I'm guessing HAVE_STDIO_EXT_H won't exist and needs to be defined to
0, but I didn't really know. HAVE_STRCASECMP and the other HAVE_s, I
have no idea about. I have no idea about optarg, optind, and optopt
either. Those need to be defined to rpl_optarg, rpl_optind, and
rpl_optopt, respectively, if they don't exist on Windows. These
globals are normally exported as part of the getopt() function. I
gathered that Windows wouldn't have a GNU compatible getopt(), but
didn't know if it had some form of getopt() which did export these
variables.
The Windows Build completes without any of the above. I don't claim to
know or imply that means anything about the function of the executable.
Well, it would complete - these are issues the GNULIB modules are
designed to work around, but at least in theory, it is better to get
them right to track API changes and the like.
Post by Conrad T. Pino
I really can't claim authorative knowledge about Windows having a GNU
compatible "getopt" function. I coded a test program with a "getopt"
call with no arguments and the linker was unable to resolve it.
It almost certainly isn't. GNU has a lot of extensions. Most UNIX
getopts are not GNU compatible. That's why I guessed and just defined
this one.
Post by Conrad T. Pino
The patch at the end of this message quit the "mkconfig.pl" warnings
without acutally doing anything. It's a crude starting point and I'd
like to know if you think it's worthwhile committing.
Well, it's probably worth shutting up the warnings, but it would be
better to get the defines right for efficiency and possibly for later
extensions, such as UNICODE support.

Upon further inspection, I discovered that the GNULIB getopt function
seems designed to always use the rpl_optopt, rpl_optarg, and
rpl_optind versions of the globals if the GNULIB getopt is used at
all, so I've committed definitions for those.
Post by Conrad T. Pino
I'm open to other suggestions regarding lines of investigation leading
towards a better resolution.
That just leaves the one header macro, HAVE_STDIO_EXT_H looking for
stdio_ext.h, which I am guessing Windows does not have, and the four
function macros, HAVE_STRCASECMP, HAVE_STRNCASECMP, HAVE_WMEMCHR, and
HAVE_WMEMCPY, looking for strcasecmp(), strncasecmp(), wmemchr(), and
wmemcpy(), respectively.

A quick web search on MSDN brings up entries for wmemchr() and
wmemcpy(), but none of the others. Glancing at some of the older
defines we haven't bothered with, defining HAVE_WMEMCHR & HAVE_WMEMCPY
would probably require defining at least HAVE_WCHAR_H & HAVE_WCHAR_T
too, so maybe it's not worth the trouble of investigating and testing
just now. If you don't have the time or inclination, go ahead and
commit undefs on all of them since it works now.

Cheers,

Derek

- --
*8^)

Email: ***@ximbiot.com

Get CVS support at <http://ximbiot.com>!
Conrad T. Pino
2004-10-09 21:50:44 UTC
Permalink
Hi Derek,
From: Derek Robert Price
That just leaves the one header macro, HAVE_STDIO_EXT_H looking for
stdio_ext.h, which I am guessing Windows does not have, and the four
function macros, HAVE_STRCASECMP, HAVE_STRNCASECMP, HAVE_WMEMCHR, and
HAVE_WMEMCPY, looking for strcasecmp(), strncasecmp(), wmemchr(), and
wmemcpy(), respectively.
My installation of Windows 2000 with Visual Studio 6.0 has no
"stdio_ext.h" file anywhere on the system. Looks to me like
it should be #undef HAVE_STDIO_EXT_H based on comments.

The only references are:

H:\cvs-1.12>grep -dn HAVE_STDIO_EXT_H *.h
File windows-NT\config.h:
490 #undef HAVE_STDIO_EXT_H

H:\cvs-1.12>grep -dn HAVE_STDIO_EXT_H *.c
File lib\getpass.c:
26 #if _LIBC
27 # define HAVE_STDIO_EXT_H 1
28 #endif
33 #if HAVE_STDIO_EXT_H

H:\cvs-1.12>

and a #undef work with the above.
A quick web search on MSDN brings up entries for wmemchr() and
wmemcpy(), but none of the others. Glancing at some of the older
defines we haven't bothered with, defining HAVE_WMEMCHR & HAVE_WMEMCPY
would probably require defining at least HAVE_WCHAR_H & HAVE_WCHAR_T
too, so maybe it's not worth the trouble of investigating and testing
just now. If you don't have the time or inclination, go ahead and
commit undefs on all of them since it works now.
The web search of MSDN I assume is same as yours and I read that to
mean they are in Visual Studio .NET and not in Visual Studio 6.0 since
my trial program with VC6 fails to resolve any of the 4 functions.

I will commit 5 #undef additions later (tonight or tomorrow) barring
any objections made known before then.
Cheers,
Derek
Conrad
Derek Robert Price
2004-10-09 23:14:43 UTC
Permalink
Post by Conrad T. Pino
The web search of MSDN I assume is same as yours and I read that to
mean they are in Visual Studio .NET and not in Visual Studio 6.0 since
my trial program with VC6 fails to resolve any of the 4 functions.
Didn't notice the .NET bit.
Post by Conrad T. Pino
I will commit 5 #undef additions later (tonight or tomorrow) barring
any objections made known before then.
No problems here.

Cheers,

Derek

- --
*8^)

Email: ***@ximbiot.com

Get CVS support at <http://ximbiot.com>!
Conrad T. Pino
2004-10-11 17:41:15 UTC
Permalink
Hi Derek,
From: Conrad T. Pino
Sent: Saturday, October 09, 2004 14:51
I will commit 5 #undef additions later (tonight or tomorrow) barring
any objections made known before then.
I committed the above to "windows-NT/config.h.in.in" and no other file.

When I run the "windows-NT/mkconfig.pl" script there are minor output
variations in comments in the output file "windows-NT/config.h.in"
compared to output from other runs and I don't have the tools to
regenerate "windows-NT/config.h" therefore I leave reneration of

windows-NT/config.h.in
windows-NT/config.h

to those better capable of doing so.

Conrad
Derek Robert Price
2004-10-14 16:52:51 UTC
Permalink
Post by Conrad T. Pino
Hi Derek,
From: Conrad T. Pino
Sent: Saturday, October 09, 2004 14:51
I will commit 5 #undef additions later (tonight or tomorrow) barring
any objections made known before then.
I committed the above to "windows-NT/config.h.in.in" and no other file.
When I run the "windows-NT/mkconfig.pl" script there are minor output
variations in comments in the output file "windows-NT/config.h.in"
compared to output from other runs and I don't have the tools to
regenerate "windows-NT/config.h" therefore I leave reneration of
windows-NT/config.h.in
windows-NT/config.h
to those better capable of doing so.
Conrad
There was no need to regenerate the files since the undefs were
falling through from the toplevel config.h.in, but you did eliminate
the warnings. Thanks.

Cheers,

Derek

- --
*8^)

Email: ***@ximbiot.com

Get CVS support at <http://ximbiot.com>!

Loading...