Yes, that is quite possible. http://sourceforge.net/mailarchive/forum.php?thread_name=201009161641.14204.nate%40hpcintegrators.com&forum_name=virtualgl-users
and http://sourceforge.net/tracker/?func=detail&aid=3005112&group_id=117509&atid=678327 may shed some insight. Some things to try (in the order listed): (1) Running with vglrun -nodl (2) Adding import os os.environ['ABAQUS_EMULATE_OVERLAYS'] = "1" to the abaqus_v6.env file. (3) Renaming Abaqus' version of libGL.so.1 to something else. On 3/17/11 12:01 PM, r...@englobe-tec.com wrote: > > Seems like my previous messages didn't reach the list (perhaps due to > the attachments) I reproduce here the last one. Regarding to this... > could be that the libGL.so.1 used by ANSYS (installed into its > directory) has a diferent version or is conflicting with the one > provided by the system? > > ***************** > > 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 5:54 PM , r...@englobe-tec.com sent: > > I've checked that vglgears runs well with vglrun through TurboVNC. > This confirms that the problem is reduced to the concrete application. > > > On Thu 4:50 PM , "Nathan Kidd" nathan...@spicycrypto.ca sent: > > On 11-03-17 07:55 AM, r...@englobe-tec.com > <javascript:top.opencompose(> 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(> sent: > > > > On 37-01--10 02:59 PM, r...@englobe-tec.com > <javascript:top.opencompose(> > > 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
