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 ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
