[Mingw-users] getopt for Windows

[Don S. <dr...@su...>]

Hi All,

getopt, or perhaps I should say the lack of getopt, in the Windows =
environment seems to be somewhat of a recuring theme.  I thought it =
would be easy to find a current copy of getopt.c and just port it to =
Windows myself but it seems to be quite the ellusive creature.  Does =
anyone know where that ellusive critter lives?  I thought I would be =
able to find it through GNU but I must have missed something.

I found a few copies of getopt.c around the net but I don't have a clue =
as to how old or accurate they are.  I snagged one and ran it through =
VC++6 and generated a .lib from it.  I got it to compile without errors =
and the getopt.lib file made several of my link errors go away but not =
all.  I ended up with only three unresolved external symbols:

client4.obj : error LNK2001: unresolved external symbol =
_get_tty_password
client4.obj : error LNK2001: unresolved external symbol _getopt_long
client4.obj : error LNK2001: unresolved external symbol _load_defaults

Are these part of the original getopt.c package or is there a =
getopt_long source module I'm missing?

Thanks in advance

And FYI Paul G. - I'm the guy learning C/C++ by practicing with MySQL.  =
I ended up almost like you did at mysql.h as the culprit to the SOCKET =
mystery.  As you indicated, MS defines SOCKET in winsock.h and =
winsock2.h as a u_int which was defined as an unsigned int.  But I don't =
think the definition of SOCKET is the issue here.

I started my journey to mysql.h by modifying mysql_com.h.  If you'll =
remember, I was getting a parse error before "SOCKET" at line 119 of =
mysql_com.h.  That line is just trying to define a variable "fd" as type =
"SOCKET" as in:

  my_socket fd;

Changing this line to:

  unsigned int fd;

of course made the program compile - so I tracked down my_socket to find =
out where it was defined ... in mysql.h with a line:

#define my_socket SOCKET

As I'm sure you know, #define is just a simple string substitution =
whereby the compiler uses the string "SOCKET" for any occurances of =
"my_socket" it finds.  To make a long story shorter, I came to the =
conclusion that winsock.h was not included or available when this =
substitution occured and therefore the compiler didn't understand we =
were trying to use SOCKET as a type and blew away line 119 of =
mysql_com.h.

The "fix" I made to mysql.h was to #include <winsock.h> at an =
appropriate point near the beginning of mysql.h right after line 49.  =
Winsock had been included a little earlier in __LCC__ had been defined.  =
That's great if you're using the LCC compiler...  I noticed right under =
that sequence that __WIN__ was defined if _WIN32 or _WIN64 were defined =
(and __WIN__ wasn't) and almost put my include there.  But what if =
__WIN__ was defined before...

The next sequence said if __WIN__ was not defined to #define STDCALL =
---- #else ---- #define STDCALL __stdcall.  I put my #include =
<winsock.h> right under that line, just before the #endif and everything =
compile just fine now, thank you.

And what about this signed/unsigned int issue for pointers.  I certainly =
would agree that using a signed int is probably poor programming but =
does the result of adding or subtracting make any difference as far as =
the actual hexadecimal address values are concerned?  Shifting would be =
an issue but I don't remember enough signed negative integer math to =
answer the question.

Anyway, C/C++ is a hoot.  I should have dove in years ago---