linking to Microsoft DLLs (OpenGL32.dll & glut32.dll)

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++)?

Thanks for any suggestions.

Dana J.

You might try looking into MinGW at http://www.mingw.org or Dev C++ at http://www.bloodshed.net

They are both free and licensed under GNU General Public License.

opengl32.dll can be used in free compilers.

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.

Glut is somewhat tricky in DevCPP, I hear.

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)

I have libglut32.a in C:\MinGW\lib.

Any advice would be much appreciated –
Thanks!

You also should have libopengl32.a
So try adding -lopengl32

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.

Thanks to my respondents.

I’m still getting link-time errors (see below).

Any suggestions?

With thanks, Dana J.

C:\MinGW\bin\ld.exe -o cube
v.exe cubev.o -Lc:\MinGW\lib -lglut32 -lopengl32 -lglaux -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+0x15):cubev.c: undefined reference to__glutInitWithExit@12’
cubev.o(.text+0x2a):cubev.c: undefined reference to exit' cubev.o(.text+0x32):cubev.c: undefined reference to__glutCreateWindowWithExit@
8’
cubev.o(.text+0x48):cubev.c: undefined reference to exit' cubev.o(.text+0x50):cubev.c: undefined reference to__glutCreateMenuWithExit@8’

cubev.o(.text+0x33f):cubev.c: undefined reference to _alloca' cubev.o(.text+0x344):cubev.c: undefined reference to__main’

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’

This might be helpful:
http://libsdl.org/pipermail/sdl/2001-December/041097.html

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.

Also see http://jrfonseca.dyndns.org/projects/gnu-win32/documentation/porting/index.html

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. "

Originally posted by Another Friend:
[b]Also see http://jrfonseca.dyndns.org/projects/gnu-win32/documentation/porting/index.html

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.

Thanks to those who’ve contributed suggestions.

I am now at the point where I can compile and link without errors! (as follows):

C:\MinGW\bin\gcc.exe cubev.c -c -
IC:\MinGW\include\GL

C:\MinGW\MinGW32\bin\ld.exe -o cubev.exe cubev.o -LC:\Windows\System -LC:\MinGW\lib -lglut32 -lglu32 -lopengl32 -lmingw32 -lcrtdll -LC:\MinGW\lib\gcc-lib\mingw32\3.2 -lgcc

(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?

With thanks, Dana J.

CUBEV caused an invalid page fault in
module GLUT32.DLL at 0167:10007656.
Registers:
EAX=00020006 CS=0167 EIP=10007656 EFLGS=00010246
EBX=00530000 SS=016f ESP=0073fd50 EBP=0073fe08
ECX=00000000 DS=016f ESI=8177aefc FS=10ff
EDX=00000000 ES=016f EDI=00000000 GS=0000
Bytes at CS:EIP:
8b 02 a3 c4 4c 03 10 8b 0d c4 4c 03 10 c1 e1 02
Stack dump:
cb45a1ed 00000000 00000001 0282015f 9e568d7c 02820147 014f5f77 4cb2032e 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

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’

P.S. to zeckensack …

I have a “main” function (not WinMain), and so (as you can see) I’ve elected not to use the -mwindows option.

To those who’ve been following this thread …

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):

C:\MinGW\bin\gcc.exe cubev.c -o cubev.exe -lglut32 -lglu32 -lopengl32

This did the trick! An executable (cubev.exe) was created, and I was able to execute it with no errors.

Oh, joy!

“Thank you” to all who contributed.

Dana J.