Did you try renaming the version of libGL.so.1 that is installed by the
application?
On 3/21/11 11:45 AM, r...@englobe-tec.com 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" nathan...@spicycrypto.ca 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, r...@englobe-tec.com
> <javascript:top.opencompose('r...@englobe-tec.com','','','')> 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" nathan...@spicycrypto.ca
> <javascript:top.opencompose('nathan...@spicycrypto.ca','','','')> sent:
> >
> > On 11-03-17 07:55 AM, r...@englobe-tec.com
> <javascript:top.opencompose('r...@englobe-tec.com','','','')> 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" nathan...@spicycrypto.ca
> <javascript:top.opencompose('nathan...@spicycrypto.ca','','','')> sent:
> > >
> > > On 37-01--10 02:59 PM, r...@englobe-tec.com
> <javascript:top.opencompose('r...@englobe-tec.com','','','')>
> > > 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.
> http://p.sf.net/sfu/internap-sfd2d
>
>
>
> _______________________________________________
> VirtualGL-Users mailing list
> VirtualGL-Users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
VirtualGL-Users mailing list
VirtualGL-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtualgl-users
