well if you only meet problems with the .h files, feel happy… because i’ve used BC++ 5.0 for a long time and i’ve often met problems when linking with the gl libraries. And even when i got an exe file, i got runtime “unhandeld exceptions : access violation : FILENAME.DLL”.
And to answer to your question, i’ve looked at line 584 in bc++5.0 's stdlib.h. It is the end of the definition of the “max” template. Is it the same with your stdlib.h ? If yes, here’s my idea for you : I guess that glut.h attempts to define its own “max”. What you could try is to delete those few lines in stdlib.h concerning “max”, and save the result into “mystdlib.h” in bc++'s include directory. Then just include <mystdlib.h> instead of <stdlib.h> in your program.
I hope that all this will work…
[This message has been edited by Morglum (edited 07-28-2001).]
/* 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. */
I am not familiar with Win32 programming, and researching this topic will be next on my “To Do” list. But for now I just want to compile my programs. If anyone knows what’s going on, please reply. Thanks in advance.
Hey Aster. I used to work with Borland C++ 4, and I had the same issues when using glut. The sollution to my problems was using the makelib utility that ships with BC++. It takes a parameter which is the Glut dll. Can’t remember if it takes more. Anyway, it produces a new lib file, that you should use instead of the normal glut lib. This solved all my problems, dunno if it’ll do the same for you. But anyway…
The error I am talking about shows up with the new glut32.lib after using Borland implib utility. When including just glut.h, without stdlib.h, everything is fine.
[This message has been edited by Aster (edited 07-30-2001).]