Why oh why

Well I’m getting closer!

I managed to get my head around installing xFree4.0.1 and I’ve got the glut and glu libs and header files.

Compilation of the simplest program goes well, but ‘ld’ can’t link the object code to the gl libraries.

The -L params are set correctly, take a look.

gcc program.c -I/usr/local/include -I/usr/X11R6/include -L/usr/local/lib -L/usr/X11R6/lib -lglut -glu -gl -o program

The linker reckons it can’t find ‘lglut’, if I change the order of the library declarations, it says it can’t find whichever comes first in the list.

Now I double checked and everything IS where its supposed to be - so anyone know whats going on?

Thanks,
Paul.

You might try changing the order of the linked items, putting your object file before the libraries.

I got it compiling. Silly me, didn’t know that the Linux console in case sensitive so a big “DOH!” and slap on the forehead for me.

Now my executable can’t find the libraries it needs; it keeps saying that libGLU.so.1 is missing - it is, but theres a symbolic link file called libGLU.so.1 that points to libGLU.so.1.2 in the X11R6/lib directory - does this need to go anywhere else?

Interestingly I deleted the link files for libGL.so.1.2, when I did this the console said it couldn’t find libGL.so.1 - but when I re-made the symbolic link from .so.1 to .so.1.2 it worked again.

SO why does it work for libGL and not for libGLU ?

Thanks,
Paul.

Are you having an adventure with Linux?

libGL.so -> libGL.so.major
libGL.so.major -> libGL.so.major.minor

So the last one is the real deal. Just make sure you have these links setup properly.

Use ls -l to show what the links are pointing to.

/skw|d

Linux turned out to be more of an ‘adventure’ than I thought it would

Okay, getting angry now…

I deleted all the symbolic links that I made to GL related stuff and rebuilt them as you suggested in the /usr/X11R6/lib directory:

libGL.so.1.2 -> libGL.so.1 -> libGL.so
libGLU.so.1.2 -> libGLU.so.1 -> libGLu.so
libglut.so.3.7.0 -> libglut.so.3.7 -> libglut.so.3 -> libglut.so

It still gives the same error message:

“error in loading shared libraries: libGLU.so.1: Cannot open shared object file: No such file or directory.”

The symbolic linking works for libGL.so.1, so why not GLU? Could it be my versions of the library? Where did everybody get their versions from? Moreover, if they’re different can I have them?

Is there a ‘path’ like - to use the DOS analogy - that I have to set or anything? I’m getting pretty peeved now.

The path for libraries is defined in /etc/ld.so.conf. If you change this file, as root do ldconfig. This updates the ld.so.cache file.

Your gcc command line uses -L to basicly ignore the ld.so.conf file. But a binary uses it when it wants to lookup a library.

/skw|d

I’ll give this a try - thanks. I’m supposed to have looked in the multitude of ‘how-tos’ but didn’t see anything like that.

Still, I love the tab auto complete - I think I could get used to Linux

Right, the ld.so.conf file checked out - the paths were already in there. ‘ldconfig’ updated the cache and the program doesn’t complain about the lack of libraries anymore.

It does however crash with a seg fault and dumps the core before it does anything interesting though…

Suggestions? Maybe I should try a different version of glut and glu? Does anyone know where to download the binaries for these?

Thanks for all the help,
Paul.

It crashes because I don’t have a GLX X server (!) I thought that was implicit… So what now?

Excuse me, I’m kinda drunk right now.

All of this should be covered in your INSTALL docs. glx is a module loaded by the X server (edit /etc/X11/XF86Config). I don’t like how you are saying that programs are seg faulting… maybe you should install your GL drivers over from scratch?

/skw|d

Seems that "Load “GLX” " was commented out of the X server config.

Thanks for the tip, that sent me on the hunt.

Actually thanks for all your help, I’d have been buggered if it hadn’t been for you. I’d buy you a virtual beer if there was such a thing

Hi there!
I suppose you are using Mesa, the free implementation of OpenGL that is widely
used by the Linux community. If that is the case, I strongly suggest you to have a look at:
http://sourceforge.net/projects/mesa3d/

This is Mesa home page and there is a lot of information available. In particular, there are 4 mailling lists available, one of them is exactly for users having trouble with Mesa installation. Brian Paul himself, the author of Mesa, monitors the list and he is very helpfull!

Anyway, some simple things that you can do:

compile your code with -g option, for debugging:

cc -g program.c … -o program

Then run program to get the core. Then run
the debugger:

gdb program core

This should give you information about what went wrong. Perhaps you can post here the gdb diagnostic messages. You can run your program inside the debugger, with the command:

gdb program

To see which libraries your program really
needs, just type:

ldd program

Put your questions to the list, everyone will
try to help you!

Carlos

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.