By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,214 Members | 2,148 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,214 IT Pros & Developers. It's quick & easy.

Problem with compiler

P: n/a
Hello to all!

For a long time I have been "fighting" a problem compiling an OpenGL
program which uses GLUT. First I have put a question in a Watcom group
(I want to use this compiler) to which I got no reply, in an OpenGL
group somebody recommended me to use Visual C++ which I did. That worked
OK but I do would like to use Watcom.
In the meantime I found solutions to several of the errors I got but one
is left which I cannot find a solution to, my knowledge of C++-compilers
is just to limited. Any help would be very highly appreciated (and sorry
about the long message, I think it is better when one asks for help to
provide the people one is asking help of with all the information I
think is needed).

The problem is when compiling the following program with WPP386, the C++
version of Watcom. WCC386, the C version compiles OK.

My listing (from
http://www.trajectorylabs.com/gettin...gl_glut.html):

//---------------------------------------------------------------------
// Getting Started with OpenGL GLUT
// A Very Simple OpenGL Example
//
// Draws a simple window with a rectangle in it
//---------------------------------------------------------------------

/* #include <iostream.h*/
#include <stdlib.h>
#include <windows.h>
#include <Gl\gl.h>
#define GLUT_DISABLE_ATEXIT_HACK
#include <Gl\glut.h>

void init(void);
void display(void);

int main (int argc, char **argv)
{
glutInit(&argc, argv);
glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGB);
glutInitWindowSize(250, 250);
glutInitWindowPosition(100, 100);
glutCreateWindow("My First OpenGL Application");
init();
glutDisplayFunc(display);
glutMainLoop();
return 0;
}

void init(void)
{
glClearColor(0.0, 0.0, 0.0, 0.0);
glColor3f(0.0, 0.0, 1.0);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glOrtho(-10.0, 10.0, -10.0, 10.0, -10.0, 10.0);
}

void display(void)
{
glClear(GL_COLOR_BUFFER_BIT);
glRectf(-5.0, 5.0, 5.0, -5.0);
glutSwapBuffers();
}

//---------------------------------------------------------------------

The line #define GLUT_DISABLE_ATEXIT_HACK I got from an explanation on
http://www.di.unipi.it/~nids/docs/watcom_glut_sdl.shtml.

Compiling it as a C++ program gives the following output from the compiler:

C:\WATCOM\Projects>wpp386 -5s pelles.cpp
Open Watcom C++32 Optimizing Compiler Version 1.6
Portions Copyright (c) 1989-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
C:\WATCOM\H\NT\Gl\glut.h(146): Error! E867: col(38) conflict with a
previous using-decl 'exit'
C:\WATCOM\H\NT\Gl\glut.h(146): Note! N393: col(38) included from
pelles.cpp(13)
C:\WATCOM\H\stdlib.h(48): Note! N392: col(10) definition: 'void watcall
exit( int )'
pelles.cpp: 48 lines, included 46799, no warnings, 1 error

The problem is in glut.h which in its entirety can be found in the
following zip file http://www.xmission.com/~nate/glut/glut-3.7.6-bin.zip
but I will also paste the part of it in which according to the compiler
the problem occurs; there is an explanation about the "exit" thing in
this file, unfortunately my knowledge is too limited to be able to
deduct from it what I should do prevent the error from occuring.

This problem has been giving me quite a lot of headaches already (I am
not exagerating when saying that I spent at least 15 hours surfing the
web and googlegroups to find a solution, but I haven't found one... I am
already very happy that I can finally enjoy my recently bought OpenGL
book when using VC++ but as I want to get into Linux as well and
OpenWatcom is being made cross-platform I would prefer to use that, I
also like the IDE as it is quite simple (like me ;-)).

This is the part of glut.h in which the problem occurs (+ in the
beginning the explanation I mentioned), the line the compiler mentions
is put between "!'s":

/* 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. */

/* XXX This is from Win32's <process.h*/
# if !defined(_MSC_VER) && !defined(__cdecl)
/* Define __cdecl for non-Microsoft compilers. */
# define __cdecl
# define GLUT_DEFINED___CDECL
# endif
# ifndef _CRTIMP
# ifdef _NTSDK
/* Definition compatible with NT SDK */
# define _CRTIMP
# else
/* Current definition */
# ifdef _DLL
# define _CRTIMP __declspec(dllimport)
# else
# define _CRTIMP
# endif
# endif
# define GLUT_DEFINED__CRTIMP
# endif

/* GLUT API entry point declarations for Win32. */
# ifdef GLUT_BUILDING_LIB
# define GLUTAPI __declspec(dllexport)
# else
# ifdef _DLL
# define GLUTAPI __declspec(dllimport)
# else
# define GLUTAPI extern
# endif
# endif

/* GLUT callback calling convention for Win32. */
# define GLUTCALLBACK __cdecl

#endif /* _WIN32 */

#include <GL/gl.h>
#include <GL/glu.h>

#ifdef __cplusplus
extern "C" {
#endif

#if defined(_WIN32)
# ifndef GLUT_BUILDING_LIB
!!!!!!!!! extern _CRTIMP void __cdecl exit(int); !!!!!!!!!!!
# endif
#else
/* non-Win32 case. */
/* Define APIENTRY and CALLBACK to nothing if we aren't on Win32. */
# define APIENTRY
# define GLUT_APIENTRY_DEFINED
# define CALLBACK
/* Define GLUTAPI and GLUTCALLBACK as below if we aren't on Win32. */
# define GLUTAPI extern
# define GLUTCALLBACK
/* Prototype exit for the non-Win32 case (see above). */
extern void exit(int);
#endif
Like I said, any help will be highly appreciated!

Yours sincerely,
Rene

P.S. Because of my job I do not have the opportunity to sit at my
computer very often and I can never predict when that will be, so if my
reply takes a while that is not because I am not interested.

P.P.S. Please forgive me language errors, English is not my mother tongue.
Jun 17 '07 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Rene wrote:
For a long time I have been "fighting" a problem compiling an OpenGL
program which uses GLUT. First I have put a question in a Watcom group
(I want to use this compiler) to which I got no reply,
Why would you want to use a compiler that doesn't work and that nobody
supports? What's your motivation?
in an OpenGL
group somebody recommended me to use Visual C++ which I did. That
worked OK but I do would like to use Watcom.
WHY??
In the meantime I found solutions to several of the errors I got but
one is left which I cannot find a solution to, my knowledge of
C++-compilers is just to limited.
Our knowledge is limited as well. Watcom is very old, and their Open
Source version is flaky, and AFAICT, nobody seriously uses it for any
serious stuff, so I strongly recommend you to find a better compiler
for your project.
Any help would be very highly
appreciated (and sorry about the long message, I think it is better
when one asks for help to provide the people one is asking help of
with all the information I think is needed).

The problem is when compiling the following program with WPP386, the
C++ version of Watcom. WCC386, the C version compiles OK.
What you're asking is help with a particular compiler, which this NG
does not provide. This is a language newsgroup. We can [attempt to]
help you with _language_ problems, not with _compiler_ problems. The
latter kind is usually resolved in the areas where those compilers are
discussed, most *mainstream* compilers have their own forums, either
on Usenet, or on the Web, or elsewhere.

If you can't find any help in Watcom-specific forum, it means you are
most likely SOL. Change compilers.
[..problem description that involves compiler-specific stuff..]

This problem has been giving me quite a lot of headaches already (I am
not exagerating when saying that I spent at least 15 hours surfing the
web and googlegroups to find a solution, but I haven't found one... I
am already very happy that I can finally enjoy my recently bought
OpenGL book when using VC++ but as I want to get into Linux as well and
OpenWatcom is being made cross-platform I would prefer to use that, I
also like the IDE as it is quite simple (like me ;-)).
There is nothing this newsgroup can tell you. OpenWatcom is but
an implementation of the language (and I haven't heard many good things
about it, BTW). If it doesn't work for you and you can't solve it, use
either a different compiler (there are cross-platform compilers like
GNU) and a different IDE (you'll get used to any of them eventually, no
need to fixate on any single one), or use different ones on different
platforms. That's how we all do it.

Unless your boss (who pays you to do what he says) tells you to use
Watcom _and_ you cannot convince him that Watcom is not the right tool
for the job _AND_ if he insists, you cannot just pick up your stuff
and find another boss, you need to get on with the project by using
some other tools. Forget Watcom, take VC++ on Windows, G++ on Unix
(Linux), and don't look back. You've spent enough of your preciuos
energy on that nonsense already.
[..]

P.S. Because of my job I do not have the opportunity to sit at my
computer very often and I can never predict when that will be, so if
my reply takes a while that is not because I am not interested.
When you have time, you'll reply. When you reply, we'll see it.
Don't worry about it.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Jun 18 '07 #2

P: n/a
Victor Bazarov schreef:
Rene wrote:
>For a long time I have been "fighting" a problem compiling an OpenGL
program which uses GLUT. First I have put a question in a Watcom group
(I want to use this compiler) to which I got no reply,

Why would you want to use a compiler that doesn't work and that nobody
supports? What's your motivation?
Hello Victor,

First of all, thank You very much for replying. My motivation is more or
less the fact that I heard good things about Watcom. The sources of
those good things may however not be that good; just things I read every
know and again on the web, couldn't give You a real pointer, I just
"absorbed" this info.
>in an OpenGL
group somebody recommended me to use Visual C++ which I did. That
worked OK but I do would like to use Watcom.

WHY??
>In the meantime I found solutions to several of the errors I got but
one is left which I cannot find a solution to, my knowledge of
C++-compilers is just to limited.

Our knowledge is limited as well. Watcom is very old, and their Open
Source version is flaky,
I did not know that.

and AFAICT, nobody seriously uses it for any
serious stuff, so I strongly recommend you to find a better compiler
for your project.
I think that as far as Windows 98 is concerned (my hobby room machine is
a bit limited for XP but 98SE runs like a rocket on it) I will stick
with Visual Studio 6.
>Any help would be very highly
appreciated (and sorry about the long message, I think it is better
when one asks for help to provide the people one is asking help of
with all the information I think is needed).

The problem is when compiling the following program with WPP386, the
C++ version of Watcom. WCC386, the C version compiles OK.

What you're asking is help with a particular compiler, which this NG
does not provide. This is a language newsgroup. We can [attempt to]
help you with _language_ problems, not with _compiler_ problems. The
latter kind is usually resolved in the areas where those compilers are
discussed, most *mainstream* compilers have their own forums, either
on Usenet, or on the Web, or elsewhere.
I had not realized that, I am sorry.
If you can't find any help in Watcom-specific forum, it means you are
most likely SOL. Change compilers.
I guess that would be the best solution.
>[..problem description that involves compiler-specific stuff..]

This problem has been giving me quite a lot of headaches already (I am
not exagerating when saying that I spent at least 15 hours surfing the
web and googlegroups to find a solution, but I haven't found one... I
am already very happy that I can finally enjoy my recently bought
OpenGL book when using VC++ but as I want to get into Linux as well and
OpenWatcom is being made cross-platform I would prefer to use that, I
also like the IDE as it is quite simple (like me ;-)).

There is nothing this newsgroup can tell you. OpenWatcom is but
an implementation of the language (and I haven't heard many good things
about it, BTW). If it doesn't work for you and you can't solve it, use
either a different compiler (there are cross-platform compilers like
GNU) and a different IDE (you'll get used to any of them eventually, no
need to fixate on any single one), or use different ones on different
platforms. That's how we all do it.

Unless your boss (who pays you to do what he says) tells you to use
Watcom _and_ you cannot convince him that Watcom is not the right tool
for the job _AND_ if he insists, you cannot just pick up your stuff
and find another boss, you need to get on with the project by using
some other tools.
As my OpenGL programming is limited to experimenting a little as a
hobby, there is no boss whose opinion I have to care about ;-).
Forget Watcom, take VC++ on Windows, G++ on Unix
(Linux), and don't look back. You've spent enough of your preciuos
energy on that nonsense already.
That is the problem with stubborn people like me. I think in this case
persisting would not really be stubborn any more, but more like stupid.
Indeed I would better use my time enjoying the OpenGL experiments and
trying to make some nice pictures instead of torturing my brain with a
problem that may not have a solution anyway.
>P.S. Because of my job I do not have the opportunity to sit at my
computer very often and I can never predict when that will be, so if
my reply takes a while that is not because I am not interested.

When you have time, you'll reply. When you reply, we'll see it.
Don't worry about it.
That is very kind of You!

Well, thanks again for Your reply. Being stubborn as I am, I must admit
that You're point of view shows more common sense than my
not-being-able-to-admit-defeat does ;-). I will take Your advice.

Yours sincerely,
Rene
Jun 24 '07 #3

P: n/a

Rene <in*****@invalid.comwrote in message...
Victor Bazarov schreef:
If you can't find any help in Watcom-specific forum, it means you are
most likely SOL. Change compilers.

I guess that would be the best solution.
As stated, VS6 was buggy and old (pre-standard).
Try GCC(MinGW). The easiest way to get it installed is to download and
install 'Dev-C++' IDE ( with the MinGW package).

Dev-C++ IDE: http://www.bloodshed.net/ (no $s)

You won't hurt anything ( just answer 'no' when asked about file
associations during install( can also be turned on-off in the 'tools' menu),
unless you want it that way). Don't remove any of your other compilers
unless you are really cramped for space on the HardDrive. If you don't like
it, just 'un-install' it (, no garbage left over, like some).

I run win98se on my 'windows' partition, so I know Dev-C++(MinGW) works.
--
Bob R
POVrookie
Jun 24 '07 #4

This discussion thread is closed

Replies have been disabled for this discussion.