Re: [Chromium-dev] debugging app_faker

[Keith W. <ke...@tu...>]

Sean Ahern wrote:
> David Jones wrote:
> 
>>Actually, I've zoomed in on the problem.  This app that I'm using (which
>>is crap, by the way) is being very stubborn.  When I do a ldd, it displays
>>
>>libGL.so.1 => /usr/X11R6/lib/libGL.so.1 (0x401b3000)
>>
>>After I set LD_LIBRARY_PATH to anythin else like /usr/lib or
>>.../crfaker.so the app still displays
>>
>>libGL.so.1 => /usr/X11R6/lib/libGL.so.1 (0x401b3000)
>>
>>which is behavior that I have _never_ seen before. It should be relinking
>>to the GL so's that I specified.  So, chromium really has nothing to do
>>with this and I need to figure out what is going on with this app.
>>
> 
> I have seen this before with some apps.  While at Siggraph, I tried to get
> the games "tuxracer" and "Chromium BSU" to run under Chromium.  They are
> both apparently compiled in such a way that the runtime loader does not
> consult LD_LIBRARY_PATH and instead loads "/usr/lib/libGL.so.1" directly.
> The only way I was able to get it to work is to replace
> "/usr/lib/libGL.so.1" with a symlink to Chromium's crfaker lib.  (I had to
> rename the real system OpenGL something like "backuplibGL.so.1" and change
> Chromium to load that when it needed the system's OpenGL.)  Once I did
> that, I was able to have Chromium capture the OpenGL stream.  Of course,
> this method requires root access.
> 
> I don't know of an easier way around this.

Hmm for ChromiumBSU and Tuxracer, I've had no problems at all using different 
libGL's:

[root@test games]# echo $LD_LIBRARY_PATH
/home/XF4/lib
[root@test games]# ldd chromium
         libGL.so.1 => /home/XF4/lib/libGL.so.1 (0x40016000)
         libGLU.so.1 => /home/XF4/lib/libGLU.so.1 (0x40084000)
...

Don't have tuxracer handy, unfortunately, but I've been using it routinely in 
similar setups.

Keith