Fatal: Bad object file 'glut32.lib' and WINDIAPI error

Borland 5.02 on Win2000 here.
After taking the advice of FoxDie on including the windows header file to kill the Multiple Declaration WINDIAPI error I was recieving (thanks, that was pretty slick!), I run into a new error, only one that says simply “Fatal: bad object ‘glut32.lib’ near offset 0.” Also, when I try to start a new project and paste the same code in, I get the WINDIAPI error again, even with windows.h.

You may have a glut32.lib that was meant for VC++ rather than Borland. You can try rebuild the glut32.lib from the glut32.dll file using Borland’s implib app which should be with your compiler.

Windows.h has to be included BEFORE gl.h. Windows.h will #define some things like WINGDIAPI, which is used in files like gl.h. Since C/C++ files are parsed top down by the compiler, those things need to be defined before you get into gl.h, thus the reason you need windows.h before gl.h.

After implib it will works. BUT You have to know that glut 3.7.6 doesnt works on borland c++ builder. I tried some months ago and I forgot what was the problem. but it definitively doesnt works on c++ builder 5.0 (I dont know about freecommandlinetools aka bcc32).

ok, from DOS I’m running
“implib glut32.lib [d:\bc5\bin>glut32.dll”
and what’s happening is it’s taking glut32.dll, shrinking it to 124 bytes, and creating a glut32.lib that is 0 bytes. What am I doing wrong?
Now just for kicks, I compiled the program again after sticking the 0 byte glut32.lib in the include directory. Heres the error I get:
“Fatal: Bad object file glut32.lib near file offset 7569”
As oppossed to 0, what does this file offset number mean??

Please, I’m in a terrible bind. Can Borland compilers not handle GLUT or not? I’m desperately trying to make this thing work, else I cannot learn to use OpenGL. I know, this is pathetique, but damn, I’m out of resources and I can’t even get my first sample code to compile!

SenseOfLiquid,

I don’t see any reason why implib should not work on your machine. Check the syntax, I noticed a few strange characters in your command line, such as ‘[’ and ‘>’, which should not be there. Most likely, you are not specifying the correct path to glut32.dll, and implib creates an empty file.

If you want, I’ll send you the precompiled glut binaries for borland.

[This message has been edited by Aster (edited 05-26-2002).]

Aster, if you could, that would save me a great deal of pain, agony, and heartbreak! My email is LucentSky@hotmail.com
Your help is much appreciated.

With the implib command, I thought the brackets [ ] where necessary when specifying the source .dll.

[This message has been edited by SenseOfLiquid (edited 05-26-2002).]

If GLUT doesn’t work on Borland, you can use the Bloodshed DEV-C++ compiler which is free.

You can find that by searching on the web.
You should download Dev-C++ 4.0. You can get the GLUT dlls off this website. Put glut32.dll and glut.dll into WINDOWS\SYSTEM directory where the other DLLs are. Then put glut.h into DEV-c++\include\GL directory and don’t worry about glut.lib or glut.a. They already come with Dev-C++.

Do the usual putting windows.h before gl\gl.h and make sure to tell the compiler that your program is not a console application. And put -lopengl32 -lglu32
-lglut into your linker options under the project options.

Dude, just download glut.lib from here:
http://home.clara.net/paulyg/ogl.htm#Borland

Obviously, this contains the Borland version.

Alright, I did figure out my mistake in syntax with the implib command. This eliminated the glut32.lib error, and then I got similiar opengl32.lib and winmm.lib errors, which I corrected with implib. Now when I run the program, I’m getting a black screen when a flashing cursor, and an error window generated by Borland that says:

Thread Stopped:
NameOfFile.exe
Fault: Access Violation at blah blah
write of address yada yada…

I suspect that Windows sucks, and that there is an illiminati plot to thwart my programming brilliance in it’s infant stages.

Yes, Windoze does suck, but from some reason, Borland C++ 5.02 don’t like to run OpenGL apps from the tool, and I don’t know how to fix this.

Just run your app directly from Windoze Exploder. It should work fine anyways.

Is there a way to recompile the GLUT Libraries to be used with Windows XP and Visual Studio .NET?

Originally posted by rpxmaster:
[b]Yes, Windoze does suck, but from some reason, Borland C++ 5.02 don’t like to run OpenGL apps from the tool, and I don’t know how to fix this.

Just run your app directly from Windoze Exploder. It should work fine anyways.[/b]

On 05-30-2002 09:31 AM, an unregistered user named VS.NET-XP made the following remark:
Is there a way to recompile the GLUT Libraries to be used with Windows XP and Visual Studio .NET?

To tell you the truth, I don’t know if you can do this with Visual Studio Not Yet. I would imagine that if it comes with a tool, such as implib for Borland that generates Borland libs from dlls and def files, then it would be possible.

Then again, I don’t use Visual Studio Not Yet, so I don’t know for sure.

Visual Studio Not Yet --Ha ha!

I’m ditching Borland for OpenGL purposes and going with Microsoft Visual C++ 6.0. Now, I’m smart enough to put all the necessary libs and headers into their right place, but on my very first compile it tells me it cannot find gl.h. BS!!!. I know I have the file in the include directory, and I’ve tried messing with all kinds of settings, but I just can’t get rid of that error!

Did you #include <gl.h> or #include <GL/gl.h>? Most compilers (including VC6) put gl.h in a GL directory off of an include path rather than directly into the include path.

On 05-31-2002 07:13 AM, a contributor named SenseOfLiquid made the following remark:
Visual Studio Not Yet --Ha ha!

I’m ditching Borland for OpenGL purposes and going with Microsoft Visual C++ 6.0.

First off, Visual Studio Not Yet != Visual Studio 6.0, SenseOfLiquid. I know, I don’t really care for Microshaft all that much. I use Borland C++ 5.02 myself, but what I really want to try is Metrowerks CodeWarrior.

On 05-31-2002 10:34 AM, a frequent contributor named Deiussum made the following remark:
Did you #include <gl.h> or #include <GL/gl.h>? Most compilers (including VC6) put gl.h in a GL directory off of an include path rather than directly into the include path.

Second off…yeah, what he/she said.