PDA

View Full Version : Transition from Linux to Windows!?!



jerryyyyyy
04-25-2008, 09:30 AM
For many years we have developed flight simulation software for research purposes first on SGI then Linux machines. Recently I had to do some programming in C++ on a statistical program that we did in Visual Studio for Windows boxes and we purchased the 2008 Pro Version. In this process I looked up OpenGL and lo and behond it seemed to be included in the Pro package we bought.

Sooo, I took my code off the Linux box and compiled a simplified version and whaddya know, it almost compiled. But I got the enclosed error. I have Googled until blue in the face, but this forum always seems to have the answer. Any suggestions on where to go with this. The .h files are very complex, with long explanations of why there is a second exit, so I was hoping there might be a simple solution.

ERROR:

1>c:\program files (x86)\microsoft visual studio 9.0\vc\include\stdlib.h(371) : error C2381: 'exit' : redefinition; __declspec(noreturn) differs
1> c:\program files (x86)\microsoft visual studio 9.0\vc\include\gl\glut.h(146) : see declaration of 'exit'
1>c:\program files (x86)\microsoft visual studio 9.0\vc\include\stdlib.h(371) : warning C4985: 'exit': attributes not present on previous declaration.
1> c:\program files (x86)\microsoft visual studio 9.0\vc\include\gl\glut.h(146) : see declaration of 'exit'

GLUT.H EXPLANATION *GREEK TO ME):

/* Win32 has an annoying issue where there are multiple C run-time
libraries (CRTs). If the executable is linked with a different CRT
from the GLUT DLL, the GLUT DLL will not share the same CRT static
data seen by the executable. In particular, atexit callbacks registered
in the executable will not be called if GLUT calls its (different)
exit routine). GLUT is typically built with the
"/MD" option (the CRT with multithreading DLL support), but the Visual
C++ linker default is "/ML" (the single threaded CRT).

One workaround to this issue is requiring users to always link with
the same CRT as GLUT is compiled with. That requires users supply a
non-standard option. GLUT 3.7 has its own built-in workaround where
the executable's "exit" function pointer is covertly passed to GLUT.
GLUT then calls the executable's exit function pointer to ensure that
any "atexit" calls registered by the application are called if GLUT
needs to exit.

Note that the __glut*WithExit routines should NEVER be called directly.
To avoid the atexit workaround, #define GLUT_DISABLE_ATEXIT_HACK. */

ZbuffeR
04-25-2008, 10:14 AM
I vaguely remember that disabling the atexit hack worked for me.

try to add on top of your files, before including glut.h :

#define GLUT_DISABLE_ATEXIT_HACK

jerryyyyyy
04-25-2008, 11:37 AM
Nice try, but unfortunately that did not do it. I better start reading the glut.h line by line.... looks to me like it would be a solution.

Wizard of Ogz
04-25-2008, 02:13 PM
Try modifying glut.h

Find the following line (in my version of glut.h it's line #146):


extern _CRTIMP void __cdecl exit(int);


Change it to this:


extern _CRTIMP __declspec(noreturn) void __cdecl exit(int);


This worked for me when I was building projects with the VC++ compiler. I found that fix on the web. I can't remember where, but someone else deserves the credit.

Also, let me know if you have any problems with the glut timers. ;)

Zengar
04-25-2008, 04:42 PM
What about compiling the GLUT dll yourself?

jerryyyyyy
04-25-2008, 04:50 PM
Thanks. Looks like I got it by hacking away and changing the order of the headers.

Seems like I am going to have to rebuild the program piece by piece to determine what headers and libraries I need. Is there any guide anywhere that reviews any generic issues in porting from Linux over to Visual Studio (if this is at all possible).

End result one way or another will be a cleaner program.