View Full Version : Compiling glut programs with Borland C++
07-27-2001, 10:08 PM
When including glut.h and C++ iostream header, I get the following error:
Error E2337 ...\Include\stdlib.h 584: Only one of a set of overloaded functions can be "C"
Including the old C iostream.h produces the same error.
I appreciate all comments and suggestions.
07-27-2001, 11:58 PM
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).]
07-28-2001, 11:04 AM
The line 584 in the stdlib.h contains only this:
Here is something that I have found in glut.h.
/* 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.
07-29-2001, 11:13 PM
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..
07-30-2001, 05:01 AM
whoops. We don't have the same stdlib.h ... sorry.
07-30-2001, 06:52 AM
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).]
07-30-2001, 07:25 PM
I found the solution to the problem: downloaded precompiled borland glut libraries from
Powered by vBulletin® Version 4.2.3 Copyright © 2017 vBulletin Solutions, Inc. All rights reserved.