In an earlier post, I noted that I’ve installed files from the CD accompanying Edward Angel’s new book (e.g., glut32.dll).
I realize that this dll was built using Microsoft Visual C++, and, hence, can’t be used with just any object files (such as those created by DJGPP’s gcc). Similar problems probably apply to OpenGL32.dll, I would guess.
My problem is, I’m stuck with Windows for now, and need to compile OpenGL C/C++ programs that will be able to be linked to Microsoft’s dll’s. I prefer not to use Visual C++. I’ve tried DJGPP’s gcc, but am getting the idea that they’re just not compatible. I’m exploring using cygwin.
My question: how can I compile, link, and run OpenGL programs in a Windows environment using freely available software (e.g., not Visual C++)?
For DLLs, you need the proper import libraries (lib***.a; they should have come with the compiler), and link them with your projects.
If you’re going to use DevCPP (basically a VC lookalike frontend to MingW), it comes with something called DevPaks. You can see a list if you enter the ‘tools’ menu and hit ‘check for updates/packages’. You’ll find an OpenGL DevPak that’ll include a new application template, with everything already setup.
Even if you’re not going to use that template, you could compare settings, might help you find the problem.
I’m now using MinGW and cubev.c compiles successfully with:
C:\MinGW\bin\gcc.exe cubev.c -c -IC:\MinGW\include\GL
However, when I link via:
C:\MinGW\bin\ld.exe -o cubev.exe cubev.o -Lc:\MinGW\lib -lglut32
I observe errors (a sampling of which follows):
cubev.o(.text+0xf4):cubev.c:
undefined reference to _imp__glRotatef@16' ... undefined reference to_alloca’
…
undefined reference to `__main’
(and so on)
Oops, forgot something.
Undefined reference to __main looks like you’re compiling as a console app. Add -mwindows to remedy that (it should then look for WinMain instead, which is probably what you want).
Not sure about __alloca, that should be covered by the default libraries, I think.
P.S. I’m now linking in an additional library, and have resolved at least one of the “undefined references” … still having trouble finding “exit”, “_alloc”, and “__main” … (see below) … Dana J.
C:\MinGW\bin\ld.exe -o cube
v.exe cubev.o -Lc:\MinGW\lib -lglut32 -lopengl32 -lglu32
C:\MINGW\BIN\LD.EXE: warning: cannot find entry symbol _mainCRTStartup; defaulti
ng to 00401000
cubev.o(.text+0xa):cubev.c: undefined reference to exit' cubev.o(.text+0x2a):cubev.c: undefined reference toexit’
cubev.o(.text+0x48):cubev.c: undefined reference to exit' cubev.o(.text+0x33f):cubev.c: undefined reference to_alloca’
cubev.o(.text+0x344):cubev.c: undefined reference to `__main’
For example, it suggests that one link in lib -lmingw32
Also, I wonder about the suggestion to use the -mwindows option … why? because I’ve seen that when Visual C++ is used to compile, one is told to create a console application.
That page reads (in part) …
"it’s not possible link between C++ code compiled by different compilers because of the differente ABI (Application Binary Interface). This means, for instance, that you cannot build Microsoft Foundation applications (MFC) with MinGW.
You can link C code though, but due to the different libraries formats it’s better to have the code compiled by the different compiler in a DLL. "
That page reads (in part) …
"it’s not possible link between C++ code compiled by different compilers because of the differente ABI (Application Binary Interface). This means, for instance, that you cannot build Microsoft Foundation applications (MFC) with MinGW.[/b]
Correct, but it’s not an issue here:
You can link C code though, but due to the different libraries formats it’s better to have the code compiled by the different compiler in a DLL. "
DLLs use C linkage. No problem.
Re the -mwindows switch again,
Dana J.,
do you have a main function in your code, or a WinMain one? You need the -mwindows linker switch only in the latter case.
-lmingw32 will solve your undefined __alloca reference, I’ve just checked.
(notice that I’m using ld.exe from directory MinGW\MinGW32\bin, as opposed to ld.exe from MinGW\bin – what’s the difference; does it matter which I use?)
However, when I run cubev.exe, an
access violation occurs (invalid page fault – shown below) … any suggestions?
By the way, note that linking as follows gave me errors:
C:\MinGW\MinGW32\bin\ld.exe -o cubev.exe cubev.o -LC:\Windows\System -LC:\Min
GW\lib -lglut32 -lglu32 -lopengl32 -lmingw32
C:\MINGW\MINGW32\BIN\LD.EXE: warning: cannot find entry symbol _mainCRTStartup;
defaulting to 00401000
cubev.o(.text+0xa):cubev.c: undefined reference to exit' cubev.o(.text+0x28):cubev.c: undefined reference toexit’
cubev.o(.text+0x44):cubev.c: undefined reference to exit' cubev.o(.text+0x351):cubev.c: undefined reference to_alloca’
C:\MinGW\lib/libmingw32.a(gccmain.o.b)(.text+0x4e):gccmain.c: undefined referenc
e to atexit' C:\MinGW\lib/libmingw32.a(gccmain.o.b)(.text+0xc1):gccmain.c: undefined referenc e toatexit’
I (Dana J.) finally stumbled upon the correct combination! At first, I had tried compiling & linking seperately:
Step 1: gcc cubev.c -c …
Step 2: ld -o cubev.exe -cubev.o …
However, just a minute ago I decided to let gcc go ahead and link after compiling; that is, I replaced the above 2 steps by a single step (note the -o option below):