Problem when linking (GCC)

[KK]

Hi.
I found Code::Blocks yesterday and have been playing around with it for some hours now. I compiled some of my old Dev-C++-projects and they all worked, but now I tried to compile a new one and I get errors. I need to link some static libraries (libopengl32.a, libglu32.a and 3 others), and I enter them as -l<name> in my project's linker options. The code compiles, but then I get the following error message (I'll post the complete log just in case)

Code

Project   : cube
Compiler  : GNU GCC Compiler (called directly)
Directory : G:\home\kolja\dev\codeblocks\Cavern\examples\cube\
--------------------------------------------------------------------------------
Switching to target: Debug
g++.exe    -g   -I"C:\\MinGW\\include"  -I"..\\..\\..\\Cavern" -c "cube.cpp" -o ".objs\\cube.o"
g++.exe   -L"C:\\MinGW\\lib"  -o "cubed.exe"   -L"C:\\MinGW\\lib"  ".objs\\cube.o"     -llibglu32.a -llibglfw.a -llibglf.a -llibopengl32.a -l..\..\..\Cavern\libcavernd.a
C:\MinGW\bin\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe: cannot find -llibglu32.a
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 0 seconds)
0 errors, 0 warnings

Can anybody help me with this?

Thanks in advance
Kolja

[mandrav]

Just remove the "lib" prefix and the ".a" suffix, e.g. change "-llibglu32.a" to "-lglu32" (same for other libs).
If you insist on using the full name, as you do now, you must include the full path to the lib, e.g. "-l../some/where/else/libfoo.a"

HTH,
Yiannis.

[KK]

That worked, thanks.
But now I got another problem, I get undefined reference-errors all over the place although I link all the necessary libraries. Only posting one example:

Code

..\\..\\..\\Cavern/libcavernd.a(CavernApp.o)(.text+0xbbb):G:/home/kolja/dev/codeblocks/Cavern/CavernApp.cpp:260: undefined reference to `glEnable@4'

It would be great I you could help me figure that one out, too.
Kolja

[KK]

Found it out myself: I had put the library linker commands into the project options, it worked when I put them into the target options.
But why is that so? I chose "Append target options to project options", and it seems as if the used linker dirs from the project options are used by the targets, but what happens to the linker commands?

By the way, nice IDE you created. Seems to be way more stable and comfortable than Dev-C++.

Kolja

[mandrav]

Linking order is very important. What you did is you changed the libraries linking order without understanding it.
You can leave it in the project's options but you 'll have to re-arrange the libraries in the correct order...

Anyway, I 'm glad it works for you now

Yiannis.

[KK]

Then maybe you can tell me if I have a chance to put them where I wanted them: I got two targets, called Debug and Release. Both need to link opengl32, glu32, glfw and glf. Debug also has to link cavernd, while Release needs cavern. These are Debug and Release versions of a library I wrote that uses the other four libraries above. Now as it works I'm linking it before the other four, when it didn't work I linked it as the last library. Is it because of cavern using the other four that I have to link it first?

Kolja

[mandrav]

I will answer you in a generic way:

Say an app needs libFoo.a and libBar.a to link.
The point is that if libBar.a references symbols from libFoo.a, you must link libBar.a before libFoo.a.

Google for it if you need more technical info on why this happens.

For your app, put in the project's options the common libs (opengl32, glu32, etc) and put cavern* in each target. Then set the linker options policy for your targets to "Prepend target options to project options". This will cause cavern to be listed before opengl32 and the rest, so it will work.

Is it because of cavern using the other four that I have to link it first?

Exactly. Whichever unresolved symbols the linker encounters in cavern, it will try to resolve them in the following libs.

HTH,
Yiannis.

[KK]

Thanks again, now it makes sense. I had thought it was the other way around, first linking the basic libraries and then the ones using the first.

Kolja