News:

As usual while waiting for the next release - don't forget to check the nightly builds in the forum.

Main Menu

Problems linking libraries

Started by yaustar, September 15, 2005, 06:21:36 PM

Previous topic - Next topic

yaustar

Hiya,

Tried compiling several demos and its all fine till I reach any that needs libraries (eg OpenGL).

Errors I get are:
Main.cpp     undefined reference to 'glViewport@16'
Main.cpp     undefined reference to 'glMatrixMode@4'
etc

I have tried linking them under
Project -> Build Options -> Linker (under both release and debug and root)

Also the code has
#pragma comment(lib, "opengl32.lib")
#pragma comment(lib, "glu32.lib")


So I cant see whats wrong.... can someone give me a step by step guide in case I am missing anything stupid...

Thanks


thomas

Those are libraries you need to link with to build basic OpenGL applications.

Either add -lopengl32 -lglu32 to "other linker options", or add opengl32 and glu32 to link libraries on the left, or link against opengl32.dll and glu32.dll which are both found inside WINDOWS\system32.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

yaustar

Quote from: thomas on September 15, 2005, 08:00:06 PM
Those are libraries you need to link with to build basic OpenGL applications.

Either add -lopengl32 -lglu32 to "other linker options", or add opengl32 and glu32 to link libraries on the left, or link against opengl32.dll and glu32.dll which are both found inside WINDOWS\system32.
Ooooookay.... the -lopengl32 and -lglu32 in other linker options worked.... my next question is why and what does it actually do when you do that?

rickg22

-l is the GCC command to link a library. For some reason adding them to the linker libraries list didn't work in your case.... (weird)

mandrav

Quote from: rickg22 on September 15, 2005, 09:19:42 PM
-l is the GCC command to link a library. For some reason adding them to the linker libraries list didn't work in your case.... (weird)

It's not exactly "weird"...
He used #pragmas to link the libraries. These only work in MS compilers...
Be patient!
This bug will be fixed soon...

yaustar

I did link them under Linker -> Link Libraries as well but that didn't work either.. I was wondering if it would be due to importing of options and settings from a VC++ 6.0 workspace...

I am also having similar problems with another set of libraries but since it is a custom built set, it may be better to ask the author instead.

thomas

Probably not. Adding them to link libraries does exactly the same thing as -lopengl32 -lglu32, except that you can select an full pathname with a GUI file selector. But then, linking is a black art, so no guarantees.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

rickg22

Ok... let's see...

1) Search for the libraries you're linking, using windows xp's Find (in start menu). It may take a while, tho.
2) Make sure the directories where these files are located, are included in the "Linker directories".
3) Make sure the libraries are included in the "Link libraries".
4) Rebuild.

yaustar

1) Search for the libraries you're linking, using windows xp's Find (in start menu). It may take a while, tho.
> C:\Program Files\CodeBlocks\lib

2) Make sure the directories where these files are located, are included in the "Linker directories".
> Compile -> Compiler Settings -> GNU GCC Compiler -> Linker tab ->  C:\Program Files\CodeBlocks\lib

3) Make sure the libraries are included in the "Link libraries".
> Check

4) Rebuild.
> Still the same problem

thomas

Out of curiosity, does it work if you add absolute paths?
e.g.:
C:\Program Files\CodeBlocks\lib\opengl32.lib
C:\Program Files\CodeBlocks\lib\glu32.lib
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

yaustar

#10
Relative or Absolute paths didn't work either... I haven't tried a 'clean' install of codeblocks through, I just installed the latest version over an older one... .could this be a cause?

edit changed have to haven't

squizzz

Which compiler are you actually trying to use...?
Half of the post in this thread suggest it's VC Toolkit (you use #pragmas, *.libs) , other ones that it might be GCC. :) ("the -lopengl32 and -lglu32 in other linker options worked....")
It's quite confusing. :)
this space is for rent

yaustar

Sorry, I am using the GCC compiler, it's just the source is an example tutorial. I didn't know the #pragma was VC only :P

squizzz

Quote from: yaustar on September 17, 2005, 02:38:31 AM
Sorry, I am using the GCC compiler, it's just the source is an example tutorial. I didn't know the #pragma was VC only :P
Okay, as I understand "-lopengl32 -lglu32" solves your problems, but you want link libraries via GUI interface?
If so, you should add libopengl32.a and libglu32.a (you can locate these in MinGW /lib subdirectory) instead of opengl32.lib & glu32.lib.
It comes to any other lib as well, if you were linking foo.lib in your VC 6.0, you will link libfoo.a while using MinGW compiler.

Hope this solves your problem.
Greetz.
this space is for rent

mandrav

Quote from: squizzz on September 17, 2005, 11:34:13 AM
Quote from: yaustar on September 17, 2005, 02:38:31 AM
Sorry, I am using the GCC compiler, it's just the source is an example tutorial. I didn't know the #pragma was VC only :P
Okay, as I understand "-lopengl32 -lglu32" solves your problems, but you want link libraries via GUI interface?
If so, you should add libopengl32.a and libglu32.a (you can locate these in MinGW /lib subdirectory) instead of opengl32.lib & glu32.lib.
It comes to any other lib as well, if you were linking foo.lib in your VC 6.0, you will link libfoo.a while using MinGW compiler.

Or just use foo as a link library and it will be replaced by C::B depending on the used compiler, i.e. libfoo.a vs foo.lib.
Be patient!
This bug will be fixed soon...