strange g++ linking behavior depending on arguments order

Question

I was trying to compile a simple opengl program on msys using g++. To my surprise the linker was complaining on undefined references:

$ g++ -mwindows -lopengl32 glut_md2.cpp
C:\Users\...\cceQtYAy.o:glut_md2.cpp:(.text+0x67a): undefined reference to `glGenTextures@8'
C:\Users\...\cceQtYAy.o:glut_md2.cpp:(.text+0x696): undefined reference to `glBindTexture@8'
....

After googling for a while I found that the problem was in g++ arguments order:

$ g++ glut_md2.cpp -mwindows -lopengl32
--- all ok! ---

The interesting thing is that the correct argument orders in g++ is in the first example. That is:

$ g++ --help
Usage: g++.exe [options] file...
....

Am I missing something? Why moving options after the file argument makes a compilation success? I never had this issue when compiling natively on linux...

Harlene

Answer 1

I bumped into this problem once or twice, you should put -L and -l at the end of command line. g++ doesn't link, it invokes ld and pass arguments, ld man:

The linker will search an archive only once, at the location where it is specified on the command line. If the archive defines a symbol which was undefined in some object which appeared before the archive on the command line, the linker will include the appropriate file(s) from the archive. However, an undefined symbol in an object appearing later on the command line will not cause the linker to search the archive again.

ld -o /lib/crt0.o hello.o -lc

Ophidian

Strange. I think g++ should pass linking options to the linker either way cause it's very explicit in the above example. Voodoo magic... – Harlene