I''m trying to write a small OpenGL program that uses some extensions. Now, my problem is that the ATI fglrx driver doesn''t come with a libGL.a file, only with the .so. When compiling (linking to be more precise), the program is apparently linked statically against the libGL.a which makes the extension be unavailable. Now my question is: how do I use a library for which I don''t have a proper .a file? Is there a way to build that file from the .so?

.a and .so are different files that have the same functions. Linking (statically) to a .a will look like this:

gcc -o myprog myprog.c libGL.a

Linking (dynamically) to a .so will look like this:

gcc -o myprog myprog.c -lGL

You should be able to ldd your "myprog" binary after this and see that it is linked to libGL.so.

NOTE: I mentioned this in the OpenGL forum too, but you should never ever link statically to libGL.a, and you should usually not link dynamically to libGL.so, on Linux.

Use dlopen, dlsym, and dlclose to grab every OpenGL function out of the library. Setting this up is a ton of typing, but you can autogenerate it (or copy it from the Quake 2 source). It''s quite easy using SDL''s wrapper functions.

OK, turns out I had a problem with some links that upset the linker. In /usr/lib, I had a link to libGL.a but no links to the shared lib which made the linker "go static". After setting up those links properly, it''s working.

Thanks for your help and time :-)

quote: Original post by Anonymous Poster


NOTE: I mentioned this in the OpenGL forum too, but you should never ever link statically to libGL.a, and you should usually not link dynamically to libGL.so, on Linux.

Use dlopen, dlsym, and dlclose to grab every OpenGL function out of the library. Setting this up is a ton of typing, but you can autogenerate it (or copy it from the Quake 2 source). It''s quite easy using SDL''s wrapper functions.

Why would you wanna do that ?

quote: Original post by George2
Why would you wanna do that ?

1) You don''t annoy people without libGLcore, assuming you''re developing on an NVidia system.

2) You have two lines of checks for any extensions (Is it in the extension string? Is the function actually in the library?)

3) You allow people to use a libGL.so with their system that isn''t the one in their default library path. This is a convenience to everyone, developers and end users.

If you''re distributing binaries, it''s the most flexible thing you can do, and flexibility is worth its weight in gold on Linux.

It actually work once glibc gets fixed.

quote: Original post by Anonymous Poster
1) You don't annoy people without libGLcore, assuming you're developing on an NVidia system.

Seeing -lGL is the linker flag, what's libGLcore got to do with this.

quote:
2) You have two lines of checks for any extensions (Is it in the extension string? Is the function actually in the library?)

And how is this different then dynamic linking to libGL and using SDL_GL_GetProcAddress ?

quote:
3) You allow people to use a libGL.so with their system that isn't the one in their default library path. This is a convenience to everyone, developers and end users.

Why would people won't to have different libGL.so's ?

quote:
If you're distributing binaries, it's the most flexible thing you can do, and flexibility is worth its weight in gold on Linux.

It's not flexible, it's wasting your time.



[edited by - George2 on March 25, 2004 6:52:24 AM]