Cygwin g++ opengl linker error

This is a discussion on Cygwin g++ opengl linker error within the C++ Programming forums, part of the General Programming Boards category; I'm having a weird issue with my linker for cygwin. I've used it in the past and had success compiling ...

  1. #1
    Registered User
    Join Date
    Sep 2002
    Posts
    14

    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

  2. #2
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,333
    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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  3. #3
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,045
    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.
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  4. #4
    Registered User
    Join Date
    Sep 2002
    Posts
    14

    Continued troubles...

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

  5. #5
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,333
    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?
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  6. #6
    Ethernal Noob
    Join Date
    Nov 2001
    Posts
    1,901
    I do opengl development with glew just fine under code::blocks. Are you using pure command prompt or an ide?

  7. #7
    Registered User
    Join Date
    Sep 2002
    Posts
    14
    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.

  8. #8
    Ethernal Noob
    Join Date
    Nov 2001
    Posts
    1,901
    ah, can't help you there, sorry.

  9. #9
    Registered User
    Join Date
    Sep 2002
    Posts
    14
    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...

  10. #10
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,333
    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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  11. #11
    Registered User
    Join Date
    Sep 2002
    Posts
    14
    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...

  12. #12
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,158
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. An error is driving me nuts!
    By ulillillia in forum C Programming
    Replies: 5
    Last Post: 04-04-2009, 09:15 PM
  2. Errors including <windows.h>
    By jw232 in forum Windows Programming
    Replies: 4
    Last Post: 07-29-2008, 01:29 PM
  3. Please Help - Problem with Compilers
    By toonlover in forum C++ Programming
    Replies: 5
    Last Post: 07-23-2005, 10:03 AM
  4. Couple C questions :)
    By Divx in forum C Programming
    Replies: 5
    Last Post: 01-28-2003, 12:10 AM
  5. Linking error
    By DockyD in forum C++ Programming
    Replies: 10
    Last Post: 01-20-2003, 04:27 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21