[GEM-dev] Gem (cvs) load error on debian/etch

[B. Bogart]

Thanks Johannes for the reply,

Good to know your running a similar setup, so hopefully this is easily
solved.

so indeed Gem was using a GL library in /usr/X11R6/lib/libGL.so.1 (again
no idea where it came from, no packages accept responsibility) so I
renamed that and recompiled Gem, now LDD shows the proper libGL:

        libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb7c59000)
        libGL.so.1 => /usr/lib/libGL.so.1 (0xb7bef000

LibGL is provided by nvidia-glx:

bbogart at insitu:/usr/lib$ dpkg -L nvidia-glx | grep libGL
/usr/lib/libGL.so.1.0.8776
/usr/lib/libGLcore.so.1.0.8776
/usr/lib/libGLcore.so.1
/usr/lib/libGL.so.1
package diverts others to: /usr/lib/nvidia/libGL.so.1.xlibmesa

And my mesa libs seem to be properly diverted by nvidia-glx:

bbogart at insitu:/usr/lib$ dpkg -L libgl1-mesa-glx | grep libGL
/usr/lib/libGL.so.1.2
diverted by nvidia-glx to: /usr/lib/nvidia/libGL.so.1.2.xlibmesa
/usr/lib/libGL.so.1
diverted by nvidia-glx to: /usr/lib/nvidia/libGL.so.1.xlibmesa

libGLU is provided by mesa though, could it me an interaction between
mesa GLU and nvidia GLX? Can I disable glu in the gem-build to test that
idea?

According to the debian repo the GLU lib is provided only by mesa... no
nvidia equivalent.

using grep gives me the same result, so the library should also contain
glUniform2i:

bbogart at insitu:~/pd-stuff/cvs/Gem/src$ grep glUniform2i /usr/lib/libGL.so
Binary file /usr/lib/libGL.so matches

So it should work, but I'm still getting the unresolved symbol error,
any other ideas?

.b.

IOhannes m zmoelnig wrote:
> hi
> 
> B. Bogart wrote:
>> Hey all,
>>
>> I've now got time to revisit this issue.
>>
>> #1. I've changed to the (binary blob from nvidia) that is included in
>> the non-free repos because I'm tired of the stupid manual installation
>> that needs to be done every time I update a machine. I must have run
>> that *$#%*#$ installer 100 times and wasted hours of my life. So I
>> switched to the one in the repo that will just work with debian out of
>> the box. Only issue is its a slightly older version (87xx) rather than
>> (97xx) but I was using gem user the 87xx series for ages without issues.
> 
> i am using the 8776 from the debian repository too (though i have a
> mixed stable/unstable system, but the packages installed are really
> 1.0.8776-4).
> no problems here.
> 
>> so to clarify  I *AM* using the nvidia binary driver, just the ones made
>> debian friendly in their repos:
> 
> are you sure?
> 
>> I confirmed that the GL headers I'm compiling against are provided by
>> nvidia, not mesa:
>>
>> glext.h:
>>
>>> #ifndef __glext_h_
>>> #define __glext_h_
>>>
>>> #ifdef __cplusplus
> 
>> and glext.h does include glUniform2i:
>>
>>> GLAPI void APIENTRY glUniform2i (GLint, GLint, GLint);
> 
> which is basically your problem:
> if the headers define glUniform2i but the library does not, then you get
> that error.
> 
>>
>> I'm sure I'm compiling against those headers, because they are located
>> in /usr/include/GL and the mesa headers have been renamed.
>>
>> I can see that glext.h provides the declaration for glUniform2i, but
>> what library is supposed to contain that symbol? nm says all the nvidia
>> provided libs "contain no symbols"
> 
> 
> i am not so firm with advanced things like "nm", but when i do
> "grep glUniform2i /usr/lib/libGL.so" i get
> "Binary file /usr/lib/libGL.so matches"
> 
>> too add insult to injury I have GEM working on an almost identical
>> machine at school with the same version of the nvidia driver from the
>> debian repo. If I try and load the binary built on that machine here I
>> get glUniform4iARB is unresolved. (which is defined in the same glext.h
>> header (the same one on both machines also)
> 
> 
> 
>> So it seams the binaries are not inline with the headers, so I have to
>> figure out what is different about the two machines. (in terms of GL
>> binary libs) after another hour of digging I can't tell what is the
>> difference between the two machines, my machine has /usr/lib/libGL.a
>> (which is supposedly provided by a debian package that I don't have
>> installed) but renaming it made no difference.
> 
> you should NOT have a libGL.a; the thing about using openGL hardware-
> and software- rendering on demand is about using dynamic libraries.
> 
>> I've attached my ./configure from both machines, which are pretty well
>> identical. And here are the GL packages installed on both:
> 
> 
> i haven't looked through these (yet).
> 
> 
> i do believe that you are linking against the wrong openGL library.
> 
> run "ldd Gem.pd_linux"
> if you see that it is linking against /usr/local/lib/libGL.so then you
> should remove these...
> 
> 
> hope this helps
> 
> mfgas
> IOhannes
>