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 , r...@englobe-tec.com 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" dcomman...@users.sourceforge.net 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.
>
------------------------------------------------------------------------------
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
