Another user ran into this same issue and attempted all of my proposed fixes below. None worked. At this point I'm stymied. I'm going to try bringing up a simple C# OpenGL demo in mono, but if I can't get that to fail in the same way, I don't know what else can be done without the app.
On 4/15/11 5:17 AM, DRC wrote: > David, > > We seem to have stalled out on this, and there were a lot of rapid-fire > e-mails exchanged between you and Nathan, in which multiple things were > tried and multiple interleaved results posted, so this e-mail is my > attempt to summarize what we know. I would encourage everyone involved > to attempt to consolidate their responses into one e-mail and wait for a > reply before posting another one. > > -- The problem is clearly due to librrfaker.so not being loaded properly > into the app. Thus, when the app attempts to call a GLX command, it > fails because TurboVNC has no GLX extension. > > -- After examining the VirtualGL trace output from the app, it does > appear that VirtualGL is being successfully loaded into something. GLX > functions are being called, at least initially. However, with complex > apps, one never knows whether librrfaker.so is being loaded successfully > into one process but not successfully into another. > > -- Referencing your attempt to run with vglrun -d :1.0, don't do that. > It's incorrect. -d specifies the 3D X server, which should almost > always be left at the default of :0.0. > > -- Referencing your attempt to run with -c proxy, that is implied in > TurboVNC, so no need to specify it. > > -- This type of problem is an issue between librrfaker.so and the app, > so it will not matter whether you are running in TurboVNC or using the > VGL Transport and an SSH connection. > > -- A possible explanation for the "ERROR: ld.so: object 'librrfaker.so' > from LD_PRELOAD cannot be preloaded: ignored." message is that either > the application or something else launched from the application's script > is a setuid/setgid executable (refer to Chapter 12 of the VirtualGL > User's Guide.) On modern Linux systems, this error will not prevent an > executable from launching, so if the error were being generated by an > executable in the script (other than the main application), then it > should be innocuous, but if the main application is generating the > error, then that would explain why librrfaker.so is not being loaded. > > Since you have tried moving vglrun down to the bottom of the launch > script (which I gather is a line that starts mono), then that eliminates > the possibility that something launched by the script is causing the > problem. However, mono might be setuid/setgid, or some other executable > it launches might be. > > -- We know your VirtualGL setup works, because you were able to vglrun > glxgears. > > -- The "indirect context" messages are very odd. For starters, when you > specified vglrun -d 1.0, VirtualGL never should have made it as far as > printing that message, because TurboVNC does not have a GLX extension. > The only scenario I can come up with is that somehow VirtualGL is > loading the version of libGL.so.1 that is shipped with the application. > > -- The 'Xlib: extension "NV-GLX" missing on display "localhost:10.0".' > message is innocuous and always occurs when running any type of 3D > application remotely with nVidia drivers on the server end. Blame nVidia. > > > So, let's be scientific about this and try a few different > configurations that should help me narrow down what is going on. For > each of these, post the console output (not tracing information, just > the simple output from VirtualGL and the application as you try to > launch it.) > > (A) > -- Set the setuid bit on librrfaker.so and libdlfaker.so. As root, > > chmod u+s /usr/lib/librrfaker.so > chmod u+s /usr/lib/libdlfaker.so > chmod u+s /usr/lib64/librrfaker.so > chmod u+s /usr/lib64/libdlfaker.so > > -- Use an unmodified application environment and application startup script > -- Use TurboVNC as the 2D X server > -- vglrun the application startup script with no arguments to vglrun > > If (A) doesn't work, then I need you to run the following > configurations. You've run some of these before, but I need to see the > console output from each for comparison (for instance, attached as > "consoleA.log", "consoleB.log", etc.): > > (B) > -- Leave the setuid bits set on librrfaker.so and libdlfaker.so > -- Modify the startup script so that vglrun prefixes the last command > (presumably 'mono'.) > -- Execute the modified startup script (without using vglrun) in TurboVNC > > (C) > -- Unset the setuid bits on librrfaker.so and libdlfaker.so (replace > chmod u+s with chmod u-s in the above) > -- Leave the startup script modified > -- Execute the modified startup script (without using vglrun) in TurboVNC > > (D) > -- Leave the setuid bits on librrfaker.so and libdlfaker.so unset > -- Leave the startup script modified > -- Rename any instances of libGL.so* in the application's install > directory to something else. > -- Execute the modified startup script (without using vglrun) in TurboVNC > > (E) > -- Leave the setuid bits on librrfaker.so and libdlfaker.so unset > -- Revert the startup script to its unmodified state > -- Leave the libGL.so* files renamed > -- vglrun the unmodified startup script in TurboVNC without any > arguments to vglrun. > > > > On 3/23/11 9:23 AM, Nathan Kidd wrote: >> On 11-03-23 09:48 AM, r...@englobe-tec.com wrote: >>> >>> When using launcher130 I get the following error, does it give any light >>> on the issue? >>> >>> ERROR: ld.so: object 'librrfaker.so' from LD_PRELOAD cannot be >>> preloaded: ignored. >> >> It means the system couldn't find librrfaker.so or couldn't find a >> version with the correct bit-ness (32/64). This is a situation where >> your LD_DEBUG=libs log will show you exactly which paths it tried to >> load librrfaker.so, so you can see where the problem is. >> >> -Nathan >> >> ------------------------------------------------------------------------------ >> Enable your software for Intel(R) Active Management Technology to meet the >> growing manageability and security demands of your customers. Businesses >> are taking advantage of Intel(R) vPro (TM) technology - will your software >> be a part of the solution? Download the Intel(R) Manageability Checker >> today! http://p.sf.net/sfu/intel-dev2devmar >> _______________________________________________ >> VirtualGL-Users mailing list >> VirtualGL-Users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/virtualgl-users ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
