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

[B. Bogart]

Hi all,

So I'm looking at this again, I had a /usr/X11R6 folder laying around, I
suppose the switch from xfree to xorg did not go as smoothly as it looked.

Anyhow I'm now compiling against:

        libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb7c4e000)
        libGL.so.1 => /usr/lib/libGL.so.1 (0xb7be4000)

which are provided by nvidia-glx:

% dpkg -L nvidia-glx
/usr/lib/libGLcore.so.1
/usr/lib/libGL.so.1

They do *not* contain glUniform2i, but they *do* contain:

% objdump -S  /usr/lib/libGL.so.1 | grep glUniform2i
0003d300 <glUniform2ivARB>:
   3d31c:       74 20                   je     3d33e <glUniform2ivARB+0x3e>
   3d345:       eb d7                   jmp    3d31e <glUniform2ivARB+0x1e>
0003d350 <glUniform2iARB>:
   3d36c:       74 20                   je     3d38e <glUniform2iARB+0x3e>
   3d395:       eb d7                   jmp    3d36e <glUniform2iARB+0x1e>

So what is the difference between glUniform2iARB and glUniform2i ?

I confirm I have and am compiling with ARB, whatever that is:

  misc
    using ARB-extensions : yes

I did some more digging and saw this:

% file /usr/lib/libGL.so
/usr/lib/libGL.so: symbolic link to `/usr/lib/libGL.so.1.0.8776'
% file /usr/lib/libGL.so.1
/usr/lib/libGL.so.1: symbolic link to `libGL.so.1.2'
% file /usr/lib/libGL.so.1.2
/usr/lib/libGL.so.1.2: ELF 32-bit LSB shared object, Intel 80386,
version 1 (SYSV), stripped

so libGL.so points to nvidia, but libGL.so.1 points to libGL.so.1.2
(from libgl1-mesa-glx) though dpkg -L tells me both should be diverted:

/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

BUT the latter (/usr/lib/nvidia/libGL.so.1.xlibmesa) seems to be broken:

% file /usr/lib/nvidia/libGL.so.1.xlibmesa
/usr/lib/nvidia/libGL.so.1.xlibmesa: broken symbolic link to `libGL.so.1.2'

I already did --reinstall for libgl1-mesa-glx and nvidia-glx (in that
order).

Johannes, does your machine also have that broken link and the same
diversions?

Anyhow I've emailed the maintainers to see whats going on.

Is there a way I can force gem to compile against libGL.so and not
libGL.so.1?

adding a manual link from libGL.so.1 to libGL.so makes Gem loose openGL
entirely:

configure: error: GL not found! you need openGL!!!

ARG!
Lemme know if you have any ideas...

B. Bogart

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
> 
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev
>