Thanks for all of that. The easy bits first.
I'm not sure why createSymbolicLinks() in the installation script is not
working, especially when the same command seems to be working when you do
it by hand. Perhaps a different shell is in place when python does that
command (via a system call). (Ah, looking at your error message again it
mentions sh, so this could indeed be the problem.) Once upon a time we
had the links explicitly done instead of that source command, but we
occasionally add a *.so file and it's easy to forget to add it into this
script, hence we thought it better to instead maintain a file which we
notice.
CloudUtil.so, although it exists in the C clouds directory, is not
actually used for anything yet in the Python world, hence we haven't yet
added it to the linkSharedObjs list. Of course it does no harm to have it
linked in.
When Clouds was first released the imports were such that it forced people
to compile it. But hopefully now (and in future) it will be set up so
that only if you try to use Clouds functionality will you be required to
compile the C code. The installation script compiles it automatically,
but I mean if someone does the compilation by hand.
Now the hard bit.
Let me first say that we have not had any experience with Solaris so are
pig ignorant about it. As it happens the big faculty server here has just
moved to Solaris 9 (I am told) and I'm now looking at that to see if we
can try Analysis on that. (There seem to be several options on C
compilers. We have something called Forte Developer 7 C compiler, which
seems to be some Sun compiler but obviously a different name than what you
mention so I'm not sure how they compare. We also have gcc 3.3 although
I'm not sure it's been tested out on anything yet on that machine. I'm
not sure if we have any native OpenGL on the machine, we ought to but I
can't find it yet.)
These OpenGL BadMatch errors are a bloody pain. With the recent email
exchange about SGI it seems to have been caused by Python picking up a
non-double-buffered widget somehow with the native OpenGL, but not with
Mesa. My guess is that here it's probably a different problem. On Linux
platforms there is an endless nightmare with incompatibilities between
various OpenGL implementations and somehow parts of more than one are
picked up by the loader. The main culprit is usually glut (but it could
be other combinations of OpenGL libraries). Almost anything to do with
glut seems to cause problems for most OpenGL implementations. That is one
nice thing (perhaps the main nice thing) about Mesa, they provide both
OpenGL and glut so they are pretty certain to be compatible.
Glut is currently used only to draw text in Analysis. Unless it proves
impossible (and fonts in OpenGL are horrid) we definitely intend to get
rid of it. That should remove a lot of problems (but perhaps not yours).
Until we manage (hopefully soon) to work with Analysis on solaris it's
going to be hard to say any more. Of course our server is on Solaris 9
and your machine is on Solaris 7, so that in itself might mean it's hard
to deduce anything from one situation to the other.
Wayne
On Fri, 19 Nov 2004, Bruce D. Ray wrote:
> System consists of Sun Ultra 10 with Solaris 7.
> Compiler is fully patched Sun WorkshopPro 5.0.
> OpenGL is ogl13_rt32_64.shar with the Sun patches 113886-20 and
> 113887-20 installed (order of installation is important).
>
> glut compiled from sources is 3.7 and gives libglut.a only because
> the author does not wish to deal with the differences in shared
> object compilations with different platforms.
>
> python is 2.3.4 compiled with the modification to socketmodule.c
> as noted on the sourceforge python bugtracker, item 972724 for lack
> of AF_INET6 and INET_ADDRSTRLEN in the Solaris 7 headers. Note that
> the suggestion for python 2.3.3c1, item 854823, does not produce
> the same functionality. Numeric 23.3 is also present in this python.
>
> tcl/tk is 8.3.5 with tix 8.1.4
>
> X11, GL, and libglut.a are under /usr/openwin
> python, tcl, and tk are under /usr/local
>
> As noted previously, installCode.py sets up the compilation
> correctly without modification. While the compilation itself
> does not report any errors, post compilation link generation
> reports an inability to source the link generation shell
> scripts. The error message stated that there wasn't anything
> to source. The section of code called to source the shell
> script reads:
>
> def createSymbolicLinks():
>
> os.chdir('%s/python/ccpnmr/analysis' % ccpnmr_rel_dir)
> cmds = ['source linkSharedObjs']
> runCmds(cmds)
>
> os.chdir('../clouds')
> cmds = ['source linkSharedObjs']
> runCmds(cmds)
>
> os.chdir('../../../..')
>
>
> I manually changed to the indicated directories and was able both
> to find and to source the indicated shell script. As a side note,
> I find that the utilities shared object in clouds is not linked
> to anything. After correcting this problem of unlinked shared
> objects, analysis presented its initial menu properly.
>
>
> An attempt to work through the analysis tutorial produced the
> following output:
>
>
> CCPNMR Analysis Version 1.0.b Release 19 (Copyright 2003-2004 CCPN)
> Distribution created Fri Nov 19 10:47:36 2004
> >>> start generating ccp.Method output
> start generating ccp.Nmr output
> start generating ccpnmr.Analysis output
> start generating memops.Implementation output
> Spectrum successfully opened
> X Error of failed request: BadMatch (invalid parameter attributes)
> Major opcode of failed request: 152 (GLX)
> Minor opcode of failed request: 5 (X_GLXMakeCurrent)
> Serial number of failed request: 18979
> Current serial number in output stream: 18979
>
>
> I could start a new project and save that project. I could
> open a spectrum and work through the popup windows just up
> to the point where the spectrum was to be displayed. Then
> I got the opengl error.
>
>
> Sincerely,
>
>
> --
> Bruce D. Ray, Ph.D.
> Associate Scientist, and Operations Director
> NMR Center
> IUPUI
> Physics Dept.
> 402 N. Blackford St.
> Indianapolis, IN 46202-3273
>
|
