Menu
▾
▴
Re: [VirtualGL-Users] extension
|
From: <ra...@en...> - 2011-03-23 10:29:34
|
The exact output that I get when trying through ssh is: $ /opt/VirtualGL/bin/vglrun runwb2 [VGL] NOTICE: Automatically setting VGL_CLIENT environment variable to [VGL] 10.1.255.247, the IP address of your SSh client. Xlib: extension "NV-GLX" missing on display "localhost:10.0". Xlib: extension "NV-GLX" missing on display "localhost:10.0". Thanks David On Wed 9:11 AM , ra...@en... sent: Hello! I tried with the same result. I've also tried accessing through ssh X forwarding, also with the same result. Thanks David On Mon 8:31 PM , "DRC" dco...@us... sent: Did you try renaming the version of libGL.so.1 that is installed by the application? On 3/21/11 11:45 AM, wrote: > I've tried this and there are new lines in the output. > > [VGL] WARNING: The OpenGL rendering context obtained on X display > [VGL] :0.0 is indirect, which may cause performance to suffer. > [VGL] If :0.0 is a local X display, then the framebuffer device > [VGL] permissions may be set incorrectly. > [VGL] WARNING: The OpenGL rendering context obtained on X display > [VGL] :0.0 is indirect, which may cause performance to suffer. > [VGL] If :0.0 is a local X display, then the framebuffer device > [VGL] permissions may be set incorrectly. > > And then the usual: > > Xlib: extension "GLX" missing on display ":1.0". > > I've tried with -nodl and -c proxy with the same results. > > Thanks > David > > On Mon 5:15 PM , "Nathan Kidd" sent: > > BTW, if you can't make sense from ld.log another simple way is to put > the vglrun command inside the runwb2 script (prefix the mono command). > That will narrow down if mono is unhappy or it is the script. > > -Nathan > > On 11-03-17 12:28 PM, > wrote: > > Hi Nathan, > > I wish a good healing for you. Thanks for your time and efforts. > > > > I sent the log in another mail but it seems like it was blocked > somewhere > > > > I'll go further with this since I really want to use my 3D accelerator > > remotely. Perhaps someone else in the list has seen anything similar. > > > > The first mention to librrfaker.so was the following: > > > > 22848: find library=librrfaker.so [0]; searching > > 22848: search path=/opt/gridengine/lib/lx26-amd64 (LD_LIBRARY_PATH) > > 22848: trying file=/opt/gridengine/lib/lx26-amd64/librrfaker.so > > 22848: search cache=/etc/ld.so.cache > > 22848: trying file=/usr/lib64/librrfaker.so > > > > And /usrlib64/librrfaker.so exists. > > > > The only matches for "error" are like the following: > > > > 22848: /usr/lib64/gconv/ISO8859-15.so: error: symbol lookup error: > > undefined symbol: gconv_end (fatal) > > 23134: /ansys_inc/v130/Framework/bin/Linux64/libComponentSystem.so: > > error: symbol lookup error: undefined symbol: CoInitialize (fatal) > > 23134: /ansys_inc/v130/Framework/bin/Linux64/libLocalization.Base.so: > > error: symbol lookup error: undefined symbol: GetTranslationW (fatal) > > > > Thanks! > > > > > > On Thu 4:50 PM , "Nathan Kidd" > sent: > > > > On 11-03-17 07:55 AM, > wrote: > > > "LD_PRELOAD=librrfaker.so ls" returned the usual ls output (no error > > > messages there). So I atach ld.log files to this mail. > > > > > > Using LD_DEBUG_OUTPUT to something like ld.log kept returning that > > grep > > > output in the console, even unsetting +tr or setting VGL_LOG. I set > > > LD_DEBUG_OUTPUT to an absolute path into my home dir and it > > worked. But > > > output was split in many files. I send you them compressed in one > > tar.gz. > > > > > > I also atach a compressed vgl.log. > > > > I don't see anything attached. > > > > However, my health has been going up and down for a while and seems to > > be going down again right now, so I won't likely look at that log for a > > good while. Sorry. > > > > What *you* can look for is which process is execing, and does it try to > > load librrfaker, and if so does it succeed; if not what paths did it > > try. > > > > -Nathan > > > > > On Wed 9:23 PM , "Nathan Kidd" > sent: > > > > > > On 37-01--10 02:59 PM, > > > > wrote: > > > > I've tried the suggestions you gave: > > > > > > > > 1.- Adding -oglhw gave no apparent result > > > > > > > > 2.- Adding those 2 lines to the script added the following lines > > > to the > > > > output: > > > > > > > > libdlfaker.so:librrfaker.so > > > > > > > > > /ansys_inc/v130/Framework/bin/Linux64:/ansys_inc/v130/CommonFiles/Help/Assistant_linux:/ansys_inc/v130/Tools/Qt/Linux64/lib:/ansys_inc/v130/Tools/mono/Linux64/lib:/opt/gridengine/lib/lx26-amd64:/ansys_inc/v130/Addins/./EngineeringData/bin/Linux64:/ansys_inc/v130/Addins/./DesignXplorer/bin/Linux64:/ansys_inc/v130/Addins/./DesignXplorer/bin/Linux64/locale/ja_JP:/ansys_inc/v130/Addins/./DesignXplorer/bin/Linux64/locale/en_US:/ansys_inc/v130/Addins/./TestingAddin/bin/Linux64:/ansys_inc/v130/Addins/./Ansoft/bin/Linux64 > > > > > > So VirtualGL's lib path isn't there, but I'm reminded that vglrun > > works > > > a little differently than how I usually launch VirtualGL; it expects > > > librrfaker.so to be in the lib path. A simple way to ensure > they're in > > > the lib path is to run: > > > > > > LD_PRELOAD=librrfaker.so ls > > > > > > If the command fails to run (can't find librrfaker.so) then the > > > issue is > > > with library path setup on your box. If it works then we'll probably > > > need to see the ld.log output. > > > > > > > 3.- Setting the environment vars: > > > > > > > > export LD_DEBUG_OUTPUT=ld.log > > > > export LD_DEBUG=libs > > > > > > > > Resulted in the application not being launched and the output is > > like > > > > the following: > > > > > > > > $ /opt/VirtualGL/bin/vglrun > > > /ansys_inc/v130/Framework/bin/Linux64/runwb2 > > > > -oglhw > > > > grep: find: No such file or directory > > > > grep: library=libdlfaker.so: No such file or directory > > > > > > I think you also ran with vglrun with +tr right? The script died > > > because > > > VGL's trace logs were captured in some of the scripts commands. > > > > > > When using the +tr command with a script you pretty-well *must* > > specify > > > VGL_LOG=vgl.log to prevent the trace output from confusing any > > commands > > > in the script that are capturing output (since all the scripts > > commands > > > get the faker loaded too). > > > > > > If you run again with VGL_LOG and the LD_DEBUG variables set then > > > perhaps vgl.log and ld.log will tell us something useful. > > > > > > Please zip the logs to avoid any problem with the mailing list > > blocking > > > things too large. > > > > > > -Nathan > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > |