body { font-family: Arial,Helvetica,sans-serif; font-size: 12px; }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 sent:
 On 11-03-17 07:55 AM, 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 sent:
 >
 >     On 37-01--10 02:59 PM, 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

Reply via email to