 |
SEARCH
TOOLBOX
LANGUAGES
Forum Menu
ECCE 6.3 apps won't start
From NWChem
Viewed 2464 times, With a total of 34 Posts
|
|
|
Clicked A Few Times
Threads 1
Posts 15
|
|
| 5:41:31 AM PDT - Wed, Apr 25th 2012 |
|
I have installed ECCE 6.3 on our RHEL5-based cluster. I can successfully bring up the gateway and login, however, when I click the builder icon it says "Unable to start the application". I get the same error when I click the viewer icon. The organizer, machine browser, and periodic table icons all work.
Where can I look to trouble-shoot the problem with builder and viewer?
|
|
|
|
|
|
Gets Around
Threads 1
Posts 48
|
|
| 9:39:05 AM PDT - Thu, Apr 26th 2012 |
|
This is undoubtedly an OpenGL related issue. You can just invoke "ebuilder" rather than "ecce" to start the builder directly while trying to resolve this issue.
Most likely you installed the 64-bit distribution of ECCE, so my comments are dependent on that. For 64-bit, ECCE does not distribute OpenGL libraries like we do for 32-bit ECCE. So you need to have OpenGL installed already on your system. The "prerequisite software check" that is option #2 from the ECCE install script menu, the very last check it does is whether you have these libraries. You can re-run the installation just to do the prerequisite check option and then do a ctrl-C exit from the install script after the check rather than doing an actual install. It could also be that you have the libraries, but they aren't in a location where they are found by ECCE. That's not too likely, but if the prerequisite check finds them and my next recommendation doesn't, that's what is happening.
The next debugging recommendation is to edit the ebuilder script in $ECCE_HOME/scripts and temporarily add an "ldd ./builder" command just before the very last line that invokes the builder. Then run ebuilder again and see if it finds libGL.so.1 and libGLU.so.1 (you'll see a lot of libraries scroll by from the ldd output so they will be somewhere in there). If not, you'll need to install those.
Assuming the libraries are missing from both the prerequisite check and running ebuilder, the package names you'll need to install are mesa-libGL and mesa-libGLU using the "yum install" command. If you haven't used "yum" before or don't have root/sudo permission on your cluster then you'll need to get your system administrator to do the install. It's possible you have libGL, but not libGLU (I've seen this on my own RHEL5 workstation). In that case of course you only need the mesa-libGLU package. Those packages will install to standard locations where ECCE should be able to find the libraries as soon as you install them. If you think you might ever build ECCE from source code, then you might as well install the development version of those packages instead: mesa-libGL-devel and mesa-libGLU-devel. That installs the header files as well as the OpenGL shared libraries need to compile ECCE.
Finally, the fallback for any platform type issue with running ECCE such as missing shared libraries is to build ECCE from the source code distribution. The build process is more rigourous in terms of checking for required packages and the software will fail to build if everything is not present. The good thing about this will be that it will be more obvious what is missing vs. running the ECCE binary distributions where it is an all-or-nothing proposition typically unless you are adept at troubleshooting as I tried to lead you through above. Building ECCE is not overly difficult given the build_ecce script and documentation included with the source code distribution.
Gary
|
|
Edited On 1:20:22 PM PDT - Thu, Apr 26th 2012 by Gary
|
|
|
|
|
|
Clicked A Few Times
Threads 1
Posts 15
|
|
| 5:53:51 AM PDT - Fri, Apr 27th 2012 |
|
Gary, thanks for the information. I do have the mesa-libGL* packages installed, and they have put things in the standard places, /usr/lib64, /usr/lib, etc., however the configuration script isn't finding them. The output from ldd ./builder shows that it's finding all the libraries though. I guess I'll have to fallback to your suggestion of building it from source.
FYI, here is the ldd builder output:
ldd builder
linux-vdso.so.1 => (0x00002aaaaaaab000)
libeccewxguicomm.so => ../lib/libeccewxguicomm.so (0x00002aaaaaab1000)
libeccewxviz.so => ../lib/libeccewxviz.so (0x00002aaaaacc0000)
libeccewxinv.so => ../lib/libeccewxinv.so (0x00002aaaaaff3000)
libeccevizsg.so => ../lib/libeccevizsg.so (0x00002aaaab22b000)
libeccemoiv.so => ../lib/libeccemoiv.so (0x00002aaaab623000)
libecceinv.so => ../lib/libecceinv.so (0x00002aaaabad3000)
libeccecommxt.so => ../lib/libeccecommxt.so (0x00002aaaac2a8000)
libeccecomm.so => ../lib/libeccecomm.so (0x00002aaaac4f7000)
libeccercmd.so => ../lib/libeccercmd.so (0x00002aaaac718000)
libeccewxgui.so => ../lib/libeccewxgui.so (0x00002aaaac93d000)
libeccewxplotctrl.so => ../lib/libeccewxplotctrl.so (0x00002aaaace63000)
libeccewxthings.so => ../lib/libeccewxthings.so (0x00002aaaad131000)
libecceedsi.so => ../lib/libecceedsi.so (0x00002aaaad39f000)
libeccedav.so => ../lib/libeccedav.so (0x00002aaaad78a000)
libeccecipc.so => ../lib/libeccecipc.so (0x00002aaaad9d8000)
libeccefaces.so => ../lib/libeccefaces.so (0x00002aaaadbfe000)
libeccexml.so => ../lib/libeccexml.so (0x00002aaaade24000)
libeccetdat.so => ../lib/libeccetdat.so (0x00002aaaae266000)
libecceutil.so => ../lib/libecceutil.so (0x00002aaaae6a2000)
libutil.so.1 => ../3rdparty/system/lib/libutil.so.1 (0x00000039ade00000)
libxerces-c.so.28 => ../3rdparty/xerces/lib/libxerces-c.so.28 (0x00002aaaae974000)
libxerces-depdom.so.28 => ../3rdparty/xerces/lib/libxerces-depdom.so.28 (0x00002aaaaef8c000)
libwx_gtk2_ewxaui-2.8.so => ../3rdparty/wxwidgets/lib/libwx_gtk2_ewxaui-2.8.so (0x00002aaaaf201000)
libwx_gtk2_adv-2.8.so.0 => ../3rdparty/wxwidgets/lib/libwx_gtk2_adv-2.8.so.0 (0x00002aaaaf494000)
libwx_gtk2_richtext-2.8.so.0 => ../3rdparty/wxwidgets/lib/libwx_gtk2_richtext-2.8.so.0 (0x00002aaaaf77d000)
libwx_gtk2_aui-2.8.so.0 => ../3rdparty/wxwidgets/lib/libwx_gtk2_aui-2.8.so.0 (0x00002aaaafa83000)
libwx_gtk2_xrc-2.8.so.0 => ../3rdparty/wxwidgets/lib/libwx_gtk2_xrc-2.8.so.0 (0x00002aaaafcf4000)
libwx_gtk2_qa-2.8.so.0 => ../3rdparty/wxwidgets/lib/libwx_gtk2_qa-2.8.so.0 (0x00002aaaaff8c000)
libwx_gtk2_html-2.8.so.0 => ../3rdparty/wxwidgets/lib/libwx_gtk2_html-2.8.so.0 (0x00002aaab01ae000)
libwx_gtk2_core-2.8.so.0 => ../3rdparty/wxwidgets/lib/libwx_gtk2_core-2.8.so.0 (0x00002aaab0460000)
libwx_base_xml-2.8.so.0 => ../3rdparty/wxwidgets/lib/libwx_base_xml-2.8.so.0 (0x00002aaab0a86000)
libwx_base_net-2.8.so.0 => ../3rdparty/wxwidgets/lib/libwx_base_net-2.8.so.0 (0x00002aaab0cb0000)
libwx_base-2.8.so.0 => ../3rdparty/wxwidgets/lib/libwx_base-2.8.so.0 (0x00002aaab0ee1000)
libXt.so.6 => /usr/lib64/libXt.so.6 (0x00000037e0a00000)
libX11.so.6 => /usr/lib64/libX11.so.6 (0x00000037e2600000)
libwx_gtk2_gl-2.8.so.0 => ../3rdparty/wxwidgets/lib/libwx_gtk2_gl-2.8.so.0 (0x00002aaab121a000)
libGL.so.1 => /usr/lib64/libGL.so.1 (0x00000037e0e00000)
libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x00000037e1600000)
libjpeg.so.62 => ../3rdparty/system/lib/libjpeg.so.62 (0x00000039a4c00000)
libstdc++.so.6 => ../3rdparty/system/lib/libstdc++.so.6 (0x00000039a5800000)
libm.so.6 => /lib64/libm.so.6 (0x00000037e0600000)
libgcc_s.so.1 => ../3rdparty/system/lib/libgcc_s.so.1 (0x00000039a4400000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00002aaab143f000)
libc.so.6 => /lib64/libc.so.6 (0x00000037dfe00000)
libgtk-x11-2.0.so.0 => /usr/lib64/libgtk-x11-2.0.so.0 (0x00000037ee600000)
libgdk-x11-2.0.so.0 => /usr/lib64/libgdk-x11-2.0.so.0 (0x00000037ed200000)
libatk-1.0.so.0 => /usr/lib64/libatk-1.0.so.0 (0x00000037ef800000)
libgdk_pixbuf-2.0.so.0 => /usr/lib64/libgdk_pixbuf-2.0.so.0 (0x00000037ec600000)
libpango-1.0.so.0 => /usr/lib64/libpango-1.0.so.0 (0x00000037ee200000)
libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00000037e3200000)
libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x00000037e5600000)
libdl.so.2 => /lib64/libdl.so.2 (0x00000037e0200000)
libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x00000037e7a00000)
libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00000037e1e00000)
libXinerama.so.1 => /usr/lib64/libXinerama.so.1 (0x00000037eda00000)
libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00000037e1a00000)
libSM.so.6 => ../3rdparty/system/lib/libSM.so.6 (0x00000039a5000000)
libpng12.so.0 => ../3rdparty/system/lib/libpng12.so.0 (0x0000003c61600000)
libz.so.1 => /usr/lib64/libz.so.1 (0x00002aaab165f000)
libtiff.so.3 => ../3rdparty/system/lib/libtiff.so.3 (0x00000039b2a00000)
libSDL-1.2.so.0 => ../3rdparty/system/lib/libSDL-1.2.so.0 (0x00000039b4200000)
libICE.so.6 => ../3rdparty/system/lib/libICE.so.6 (0x00000039a4800000)
libXau.so.6 => /usr/lib64/libXau.so.6 (0x00000037e2200000)
libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00000037e2a00000)
libXext.so.6 => /usr/lib64/libXext.so.6 (0x00000037e4200000)
libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00000037e1200000)
/lib64/ld-linux-x86-64.so.2 (0x00000037dfa00000)
libpangocairo-1.0.so.0 => /usr/lib64/libpangocairo-1.0.so.0 (0x00000037ef400000)
libcairo.so.2 => /usr/lib64/libcairo.so.2 (0x00000037eaa00000)
libfontconfig.so.1 => ../3rdparty/system/lib/libfontconfig.so.1 (0x00000039a2400000)
libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00000037e9600000)
libXi.so.6 => /usr/lib64/libXi.so.6 (0x00000037eca00000)
libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x00000037eec00000)
libXcursor.so.1 => /usr/lib64/libXcursor.so.1 (0x00000037ed600000)
libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00000037ef000000)
librt.so.1 => /lib64/librt.so.1 (0x00002aaab187a000)
libesd.so.0 => ../3rdparty/system/lib/libesd.so.0 (0x00000039af200000)
libaudiofile.so.0 => ../3rdparty/system/lib/libaudiofile.so.0 (0x00000039af600000)
libpangoft2-1.0.so.0 => /usr/lib64/libpangoft2-1.0.so.0 (0x00000037ede00000)
libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00000037e6e00000)
libexpat.so.0 => ../3rdparty/system/lib/libexpat.so.0 (0x00000039a2000000)
libasound.so.2 => ../3rdparty/system/lib/libasound.so.2 (0x00000039ad600000)
Mike
|
|
|
|
|
|
Gets Around
Threads 1
Posts 48
|
|
| 9:57:09 AM PDT - Fri, Apr 27th 2012 |
|
Mike,
Have you successfully run a previous version (before 6.3) of the ECCE Builder? If you have the GL test application glxgears on your system, I'd try running that. It should be in /usr/bin if you have it. That would tell you whether it's an ECCE-related issue or a generic OpenGL issue you are having. You can do an "ldd /usr/bin/glxgears" to make sure it is using the exact same GL libraries as ECCE.
Do you get any terminal output at all from running ebuilder (when the ldd command isn't there)? Does it give a "Segmentation fault" message or anything? Edit the ebuilder script again, duplicate the last line that invokes builder, comment out one of the duplicate lines with a "#" sign, and then modify the other by removing removing the first "|&" and everything after it (that logic is used to filter out some annoying warnings that normally don't indicate an actual problem). Send me the output from that.
I do agree that building from source code is a reasonable next step. Another option is trying to get the 32-bit distribution of ECCE working on your 64-bit cluster. While doing all the source code packaging for the ECCE 6.3 release I did see that there are 64-bit vs. 32-bit OpenGL issues so I wouldn't be surprised if the 32-bit distribution worked. More than likely you already have the necessary 32-bit compatibility libraries on your system (definitely you do if you ran ECCE prior to 6.3 on this cluster). The most likely ones you don't have would again be the GL libraries. But, you can install those with yum (package names are mesa-libGL.i386 and mesa-libGLU.i386). The only thing you lose by going with a 32-bit distribution is a bit of speed perhaps in some areas like Viewer MO calculations. Finally, if you try the 32-bit distribution and it doesn't work for you, you can modify the $ECCE_HOME/siteconfig/site_runtime file to specify that the OpenGL libraries shipped with ECCE be used instead of the local one you installed (search for "MESA" in site_runtime and comment out the two lines setting the related variables).
Gary
|
|
|
|
|
|
Clicked A Few Times
Threads 1
Posts 15
|
|
| 10:24:54 AM PDT - Fri, Apr 27th 2012 |
|
Gary,
This is the first time we've tried to use ECCE on this cluster. We have ECCE 6.0 on another cluster, but I see it's the 32-bit version. I ran glxgears and it works fine, it's using the same GL libraries as ECCE.
If I run ebuilder I do get a segmentation fault. I made the edits you suggested to the ebuilder script such that the last line looks like "./builder -standalone $file". When I run it, again all I get is segmentation fault.
I will try the 32-bit version.
Mike
|
|
|
|
|
|
Clicked A Few Times
Threads 1
Posts 15
|
|
| 10:36:25 AM PDT - Fri, Apr 27th 2012 |
|
Gary,
The 32-bit version works! Apparently there is a problem with using 64-bit OpenGL.
Mike
|
|
|
|
|
|
Gets Around
Threads 1
Posts 48
|
|
| 10:59:20 AM PDT - Fri, Apr 27th 2012 |
|
Mike,
Did you try glxgears? If that didn't work for you, then yes you wouldn't be able to get 64-bit ECCE to work without resolving the issue so that glxgears would run. If you want I can provide you with the 64-bit OpenGL libraries that I (successfully) use when running ECCE on RHEL 5.8 and tell you where to put them so your 64-bit distribution of ECCE uses those. Or, you can stick with the 32-bit distribution since that obviously didn't take much work to get going.
Gary
|
|
|
|
|
|
Clicked A Few Times
Threads 1
Posts 15
|
|
| 11:36:08 AM PDT - Fri, Apr 27th 2012 |
|
Gary,
I did run glxgears and it did work, so I think my OpenGL libraries are ok. I'm fine to stick with the 32-bit version right now since apparently that's what we've used up to now anyway.
Mike
|
|
|
|
|
|
Gets Around
Threads 1
Posts 48
|
|
| 12:09:42 PM PDT - Fri, Apr 27th 2012 |
|
| Yes, ECCE 6.3 is the first time we've ever had a native 64-bit distribution (applications). Since all the work was done to be able to build 64-bit applications from the ECCE source code distribution there was no reason not to distribute a 64-bit binary distribution to save people time/effort if they didn't already have 32-bit compatibility libraries installed, 32-bit OpenGL, etc.
|
|
|
|
|
|
Gets Around
Threads 1
Posts 48
|
|
| 12:34:41 PM PDT - Fri, Apr 27th 2012 |
|
Hi Mike,
I went ahead and created a new ECCE 64-bit distribution in our normal download area that bunldes the Mesa OpenGL 64-bit libraries used on my RHEL 5.8 build. It would be great if you could try out that version to see if it also fixes your problem like the 32-bit ECCE distribution does.
You'll need to make one minor change though in order for ECCE to use those bundled libraries instead of your /usr/lib64 ones. After installing the new download and before starting ebuilder or ecce, edit the $ECCE_HOME/siteconfig/site_runtime file. Search for "ECCE_MESA_EXCEPT" and comment that line out by adding a "#" sign in the first column. Then try starting ebuilder and let me know if it works for you. Of course I wouldn't remove the 32-bit install of ECCE right away since that one is known to work.
Thanks,
Gary
|
|
|
|
|
|
Clicked A Few Times
Threads 1
Posts 15
|
|
| 1:43:10 PM PDT - Fri, Apr 27th 2012 |
|
Gary,
Thanks, I think I will try that. We're seeing a problem with the 32-bit version working from PC clients that logon to the cluster using X-win32 for X-windows support. An older version of X-win32 works, but newer versions don't. We think they may not be handling the 32-bit version. It works fine from Linux workstations.
So I'll try the new 64-bit version and let you know.
Thanks,
Mike
|
|
|
|
|
|
Gets Around
Threads 1
Posts 48
|
|
| 2:12:00 PM PDT - Fri, Apr 27th 2012 |
|
Hmmm, that seems odd. Worth trying the 64-bit version, but I'm not up on these X Windows emulation packages to offer any guidance.
Gary
|
|
|
|
|
|
Clicked A Few Times
Threads 1
Posts 15
|
|
| 8:03:30 AM PDT - Mon, Apr 30th 2012 |
|
Gary,
I tried the new 64-bit version, however when I try to run ebuilder I get:
builder: error while loading shared libraries: libnvidia-tls.so.290.10: cannot open shared object file: No such file or directory
I don't find this file anywhere in the ecce installation.
Mike
|
|
|
|
|
|
Gets Around
Threads 1
Posts 48
|
|
| 12:08:18 PM PDT - Mon, Apr 30th 2012 |
|
Mike,
I unknowingly packaged up the NVidia specific version of libGL.so that I run on my 64-bit RHEL 5.8 workstation. I see two possible fixes. One is that I go back to using software-only OpenGL on my workstation and the other is packaging the libnvidia libraries in a new 64-bit ECCE distribution and seeing if that works for you.
I'm going to try the second approach initially because I prefer to keep using the NVidia drivers if I can. I just updated the distributions that can be downloaded. Download the latest 64-bit one and try again. I'll cross my fingers, but I think there's a good chance this won't work without having the required graphics card. It's worth a try though. Thanks for hanging in there.
Gary
|
|
|
|
|
|
Gets Around
Threads 1
Posts 48
|
|
| 1:01:40 PM PDT - Mon, Apr 30th 2012 |
|
Mike,
I just tried building ECCE with the "software-only" OpenGL libs available via yum (no NVidia linkages). That included recompiling all of the ECCE viz-related code using these versions of the libraries and include files. Unfortunately I'm getting a segmentation fault. That means that packaging up the NVidia shared libraries as I have done is the only solution I'll have for you.
Let me know if that version works. If it doesn't then you'll need to go back to the 32-bit distribution of ECCE and try to figure out the issue with the X-win32 application. I'll also remove those OpenGL libraries completely from the 64-bit ECCE binary distribution because they wouldn't work for anyone.
Gary
|
|
|
|
|
|
Gets Around
Threads 1
Posts 48
|
|
| 4:58:53 PM PDT - Mon, Apr 30th 2012 |
|
Hi Mike,
If you can't get the latest 64-bit ECCE binary distribution to work I think it's finally time to try to build ECCE from the source code distribution on your cluster. I'm pretty certain that will resolve your issue because it will insure consistency between all the libraries that are used. I'm not at all sure though whether it will fix your X-win32 issue. Do let me know though how it goes with trying the latest ECCE 64-bit distribution. You can also just install and try the standalone builder distribution since I updated tha as well and the OpenGL problems you are having will show up in the builder alone. If it doesn't work for you I'm going to remove all the Mesa OpenGL libraries I'm currently packaging with the binary distribution because I know they won't work for others either. Finally, don't forget when you install the latest ECCE distribution to edit the $ECCE_HOME/siteconfig/site_runtime file and comment out the ECCE_MESA_EXCEPT setting. Otherwise it will fall back to using the your local OpenGL libraries rather than the ones bundled with ECCE.
Thanks,
Gary
|
|
Edited On 5:05:35 PM PDT - Mon, Apr 30th 2012 by Gary
|
|
|
AWC's:
2.5.10 MediaWiki - Stand Alone Forum Extension
Forum theme style by: AWC
| |
