Opengl linux undefined reference to basic functions

Question

I wrote a program on Ubuntu 11.04 that uses freeglut. It worked fine. Then I got another computer and tried to run the program on a fresh install of Ubuntu 11.04. Doesn't work. So I installed

sudo apt-get install freeglut3 freeglut3-dev libglew1.5 libglew1.5-dev libglu1-mesa libglu1-mesa-dev libgl1-mesa-glx libgl1-mesa-dev mesa-common-dev gcc

and tried to run the program, which imports

    #include <GL/freeglut.h>
    #include <GL/gl.h>
    #include <GL/glu.h>

using the command

g++ -lGL -lGLU -lglut Driver.cpp -o a

However the linker or whatever spits out like 200 errors of the form:

    Driver.cpp:(.text+0x3c6b): undefined reference to `glutSolidSphere'
    Driver.cpp:(.text+0x3c75): undefined reference to `glEnable'
    Driver.cpp:(.text+0x3c9a): undefined reference to `glColor4f'
    Driver.cpp:(.text+0x3cb5): undefined reference to `glRotatef'
    Driver.cpp:(.text+0x3d02): undefined reference to `glutSolidSphere'
    Driver.cpp:(.text+0x3d07): undefined reference to `glutSwapBuffers'

What is the cause of the problem?

Solution

The order in which you specify the objects you want to link to (including static and dynamic libraries) can matter.

Try with:

g++ Driver.cpp -lGL -lGLU -lglut  -o a

(Not sure about the order of the libs, but that looks ok.)

The idea when you build your command line is that if a requires a symbol from b, b must appear after a in the command line.

The link order problem happens (or not) with GCC/ld for shared libraries depending on (most likely among other things - I'm no expert here) whether the --as-needed link flag is set or not. (See for instance the before-last item in Gentoo's as-needed transition guide.)
The linking process eliminates un-needed symbols ASAP when --as-needed is active, which causes problems if the link order is not "correct". This is done to reduce the number of un-necessary dependencies present in final executables.
This doesn't happen (or less so) if --as-needed is not active - all symbols are kept in that case, and link order doesn't matter as much (more or less - again, I'm no expert.)

Since different distributions use different defaults for that flag, the behavior of GCC might seem inconsistent, but that's just an impression.

Comments

[lvella]

That is usually an issue with statically linked libraries. I don't know what could have caused the problem with shared libraries, which are the case.