Cygwin g++ opengl linker error

I'm having a weird issue with my linker for cygwin. I've used it in the past and had success compiling code that includes opengl glut etc, but now I'm having issues.

g++ main.cpp -lglut32 -lglu32 -lopengl32 -lglew32

I can compile it in Visual studio fine but due to some issues i'm having with trying to install FLTK for it, I decided to switch to g++.

After trying to compile it tells me that there are undefined references to all of the OpenGL functions.

I've even tried explicitly pointing to the directories containing libopengl32.a with the following

g++ -L/lib/w32api/ -L/usr/X11R6/lib/ main.o -lglut32 -lopengl32 -lglu32 -lglew32

Although this cleared up my errors in finding libglew32.a, it was unsuccessful with the opengl library, giving me linking errors like:

main.o:main.cpp.text+0x1ef): undefined reference to `_glClearColor'

If anyone knows whats wrong with my setup please let me know....

Thanks

Code:

$ nm /usr/lib/libm.a | grep cos
00000000 I __imp__acos
00000000 T _acos
00000000 I __imp__acosf
00000000 T _acosf
00000000 I __imp__acosh
00000000 T _acosh
00000000 I __imp__acoshf
00000000 T _acoshf
00000000 I __imp__cos
00000000 T _cos
00000000 I __imp__cosf
00000000 T _cosf
00000000 I __imp__cosh
00000000 T _cosh
00000000 I __imp__coshf
00000000 T _coshf
00000000 I __imp__sincos
00000000 T _sincos
00000000 I __imp__sincosf
00000000 T _sincosf

The 'nm' utility tells you what symbols are defined (or extern) to an object file (or a library).
If it's unresolved in a library, then the letter code will be 'u'
Do that for one of the opengl functions (say glClearColor) to find out which libraries reference it, and which declares it.
Then arrange the library order on the command line so that everything which uses it comes before the one which declares it.

Google found this:

Code:

The source file: “glutplane.c”
g++ glutplane.c -o glutplane.exe -lglut32 -lglu32 -lopengl32
IMPORTANT: Libraries must be listed IN THE ABOVE ORDER

From http://72.14.253.104/search?q=cache:...lnk&cd=8&gl=ca

I can't find information about where glew goes, but I'd guess it probably goes first or last.

After using the nm command I found the following

From libglew32.a:
U _glGetString@4
U _wglGetCurrentDC@0
U _wglGetProcAddress@4

From libglut32.a:
U __libglut32_a_iname
U __head_libglut32_a

From libglu32.a:
U __libglu32_a_iname
U __head_libglu32_a

From libopengl32.a:
U __libopengl32_a_iname
U __head_libopengl32_a

I also tried a bunch of different orderings but to no avail...

its funny because in another program on my machine, it links fine every time and I had the order that was described...

I also noticed that it isn't finding the gluPerspective call in my code as well as the other opengl32 code. All of the GLSL code that's in the glew library as well as the glut library code is linked properly (well the glew library just isn't complained about but in the log that i've posted, it doesn't show up).

I still have been explicitly tell the compiler to look in /usr/lib/w32api (why they would put it in a separate directory is beyond me)

I run into this issue from time to time which makes me think its a bug, but lately I've been having good luck so I'm not sure.

Although I've tried many re-orderings, this was one that didn't work so I had it output information from the linker and I found:

g++ GLSL_ShaderLoader.cc main.cpp -Wl,--verbose -L /lib/w32api -lglut32 -lglu32 -lglew32 -lopengl32

....

attempt to open /lib/w32api//libglew32.dll.a succeeded
-lglew32 (/lib/w32api//libglew32.dll.a)
attempt to open /lib/w32api//libglut32.dll.a failed
attempt to open /lib/w32api//glut32.dll.a failed
attempt to open /lib/w32api//libglut32.a succeeded
(/lib/w32api//libglut32.a)dspds00082.o
(/lib/w32api//libglut32.a)dspds00094.o
(/lib/w32api//libglut32.a)dspds00057.o
(/lib/w32api//libglut32.a)dspds00037.o
(/lib/w32api//libglut32.a)dspds00038.o
(/lib/w32api//libglut32.a)dspds00041.o
(/lib/w32api//libglut32.a)dspds00012.o
(/lib/w32api//libglut32.a)dspds00018.o
(/lib/w32api//libglut32.a)dspds00043.o
(/lib/w32api//libglut32.a)dspds00047.o
(/lib/w32api//libglut32.a)dspdh.o
(/lib/w32api//libglut32.a)dspdt.o
attempt to open /lib/w32api//libopengl32.dll.a failed
attempt to open /lib/w32api//opengl32.dll.a failed
attempt to open /lib/w32api//libopengl32.a succeeded
attempt to open /lib/w32api//libglu32.dll.a failed
attempt to open /lib/w32api//glu32.dll.a failed
attempt to open /lib/w32api//libglu32.a succeeded

looking at those dspds*.o sections from the output of nm libglut32a shows that these are all the times that libglut has linked into my program. Yet even though it finds libopengl32.a, libglu32.a and libglew32.dll.a it doesn't link them right (although oddly enough i don't hear a word about the glew stuff).

Also, looking at my build from the program that does build, when it reaches libopengl32.a it starts linking everything. So I'm a little stumped...

Can you do an 'ls /lib/w32api/*.a' on both machines, and check the sizes of the various opengl library files.

Maybe one is broken, or out of date?

Also, does doing the 'nm' command on the machine which works produce different results?

I do opengl development with glew just fine under code::blocks. Are you using pure command prompt or an ide?

Pure command line, i've used code blocks in the past, but recently I've needed to work in a unix like environment, so I had be doing that instead up until now.

ah, can't help you there, sorry.

The two files are different sizes, but one of the libraries is in cygwin and the other is in visual studio which might make a difference.

I've also noticed that the actual listings from the linker look similar to this: '_glRotatef' What I noticed about this is that they only have one underscore and no number at the end where as from the nm command I found _glRotatef@16 and __imp__glRotatef@16 in the output.

I'm wondering if this has any significance...

The name mangling convention for C++ symbols varies from one compiler to another. So even if the library format is the same between the compilers, the chances are slim as to whether you'll be able to match any symbols.
Even if you do, you still have to contend with possible differences in calling conventions.

In short, the VC library will not help you with a cygwin build.

That's what I figured, which is why I'm only using the cygwin library that was provided with my distribution. Does the header file that is loaded have anything to do with how the compiler sets up the naming for the linker? I don't know if I'm using the wrong header or not, but it's just a thought...

You're probably just listing the libraries in the wrong order. A library 'X' which depends on a library 'Y' must be listed BEFORE 'Y' on the link line.

The brute force method is to just list every library twice:

Code:

g++ main.cpp -lglut32 -lglu32 -lopengl32 -lglew32 -lglut32 -lglu32 -lopengl32 -lglew32

If that works, then you've proved that the problem is simply the link order. Rearrange things so that the libraries which do not depend on any other libraries come LAST, and the other libraries come FIRST.