-   Linux - Software (
-   -   Yet another 'undefined reference' problem (

faulpelz2 04-04-2003 06:28 AM

Yet another 'undefined reference' problem

in short, I have the feeling my linker does not look at lib*.a libraries.
This is the problem:
#g++-3.2 -lGL -lGLU -lglut -L../Meshlib/Lib -lmesh main.o load.o glnav.o glnavapp.o waypoints.o fonts.o
glnavapp.o: In function `GlNavApp::debug(int)':
glnavapp.o(.text+0x1d00): undefined reference to `getFrustumGL(t_3DVector&, t_3DVector&, t_3DVector&, t_3DVector&, t_3DVector&, t_3DVector&)'

The function 'getFrustumGL' is located in the file support-opengl.o, which in turn is located in the library libmesh.a. When I take the -Lpath option out, the linker complains (of course) about not finding the library libmesh.a. When I link the program with support-opengl.o (which I have present beside the library), no error comes up.
That leads me to the assumption that the linker does not search the library correctly. Beside, the GL library only exists as, not as static libGL.a. Does that mean the linker only tries to link to shared libraries?

Does anybody have an idea?


P.S.: g++ 3.2.1 gcc 3.2.1
The library is compiled with the same version.
Debian 3.0 testing/unstable, because I need glibc 2.3 for libmesh.a

jpbarto 04-04-2003 09:33 AM

could this be the result of installing libraries and not running 'ldconfig' afterward?

faulpelz2 04-04-2003 10:50 AM

No, I don't think so. ldconfig is for dynamic libraries, and furthermore just accessible as root. In my case, I have the static library libmesh.a, which is not installed in a system path (that's why I supply the exact path with the -L option), and I don't want it to be in a system path. It's just intended for the same user who compiles the program.

jpbarto 04-04-2003 11:18 AM

I'm sorry then... I'm afraid I don't have too much experience with trouble shooting libraries...

All times are GMT -5. The time now is 06:55 AM.