Re: [Freeglut-developer] Updated OpenWatcom support patch

[Fay, J. F Dr C. U. A. 46 S. <joh...@eg...>]

OK, better late than never.  Please let me know if I've put the changes
in correctly.

John F. Fay
Technical Fellow
Jacobs Technology TEAS Group
850-883-1294 

-----Original Message-----
From: pau...@no...
[mailto:pau...@no...] 
Sent: Thursday, June 11, 2009 3:35 AM
To: fre...@li...
Subject: Re: [Freeglut-developer] Updated OpenWatcom support patch

So attached is an updated patch for OpenWatcom support - is there anyone
who will apply it for me?

-----Original Message-----
From: Sven Panne [mailto:Sve...@ae...]
Sent: Thursday, June 11, 2009 9:25 AM
To: Paul Blew; fre...@li...
Subject: Re: [Freeglut-developer] Updated OpenWatcom support patch

Am Montag, 8. Juni 2009 09:30:44 schrieb pau...@no...:
> The problem manifests itself as a compilation error (see attached).  
> It is complaining that the arguments for __glutInitWithExit do not 
> match those in the prototype.
>
> It's been a while since I used classic GLUT, but I have a dim and 
> distant memory that it was a problem there too. It seems that there is

> an assumption that if you are on Windows you must be using MSVC.
>
> A simple fix would be changing line 602 from:
>
> #if defined(_WIN32) && !defined(GLUT_DISABLE_ATEXIT_HACK)
>
> to either:
>
> #if defined(_WIN32) && !defined(GLUT_DISABLE_ATEXIT_HACK) &&
> !defined(__WATCOMC__)
>
> or:
>
> #if defined(_MSC_VER) && !defined(GLUT_DISABLE_ATEXIT_HACK)

OK, now I understand the problem: For some obscure reason, Watcom uses a
different, non-standard calling convention for C's "exit" function
("watcall" 
vs. "cdecl") than all other C runtimes. This leads to a mismatch in our
prototype and even more problems in classic GLUT.

I think doing this differently is a very, very bad idea from Watcom, so
I'm simply disabling the atexit hack for Watcom only, i.e. use the first
fix you proposed. The reason for fixing it this way is that we stay as
close to original GLUT as possible. I don't know e.g. is the atexit hack
is necessary for other development environments/runtimes, e.g. MinGW, so
let's be conservative...

Anyway, this was no show stopper, so where is our 2.6.0 release? :-(

Cheers,
   S.