The machine is an SGI Octane (R10K) running Irix 6.5.22 with MIPSpro 7.3
compilers and python 2.3.4 with numeric 23.1
SGI's GL and glut just don't work well with python for some reason.
Apparently, SGI's GL and glut are not OpenGL. There is supposed to
be a python module to translate calls for python to the SGI version
of GL, but it does not compile. Therefore, I used the ignore GL
option for tk graphics only.
X11 is in /usr
tcl8.3.5, tk 8.3.5, and python2.3.4 are all installed in /usr/local
The first problem stems from SGI's attempts at binary compatibility.
Unless compiling in "o32" mode, system libraries are always in
/usr/lib32 Thus, the 32 bit X11 library for SGI is in /usr/lib32
As with the previous version, I had to manually edit environment.txt
to change the X11 libraries reference to read /usr/lib32
After I restarted the build, I got the following errors:
cc -c -O -DDO_NOT_HAVE_MALLOC pdf_handler.c
cc-1117 cc: ERROR File = pdf_handler.c, Line = 137
An expression appears after a "return" in a "void" function.
return get_text_size_pdf_handler((Pdf_handler) data, text, w, h);
^
cc-1117 cc: ERROR File = pdf_handler.c, Line = 143
An expression appears after a "return" in a "void" function.
return fill_triangle_pdf_handler((Pdf_handler) data, x0, y0, x1, y1, x2, y2);
^
The functions called at the return are "void" functions themselves.
However, MIPSpro 7.3 c does not like the shortcut construction.
Editing to place the return after the function invocation corrected
this. However, two other cases of the same type shortcut also
interrupted the build and had to be corrected by the same type of
edit. These are as follows:
cc -c -O -DDO_NOT_HAVE_MALLOC ps_handler.c
cc-1117 cc: ERROR File = ps_handler.c, Line = 137
An expression appears after a "return" in a "void" function.
return get_text_size_ps_handler((Ps_handler) data, text, w, h);
^
cc-1117 cc: ERROR File = ps_handler.c, Line = 143
An expression appears after a "return" in a "void" function.
return fill_triangle_ps_handler((Ps_handler) data, x0, y0, x1, y1, x2, y2);
^
cc -c -I/usr/local/include/python2.3 -I/usr/include -I/usr/local/include -I/usr/local/include -O -DDO_NOT_HAVE_MALLOC tk_handler.c
cc-1117 cc: ERROR File = tk_handler.c, Line = 200
An expression appears after a "return" in a "void" function.
return get_text_size_tk_handler((Tk_handler) data, text, w, h);
^
cc-1117 cc: ERROR File = tk_handler.c, Line = 206
An expression appears after a "return" in a "void" function.
return fill_triangle_tk_handler((Tk_handler) data, x0, y0, x1, y1, x2, y2);
^
A number of nuisance error messages about variables declared but never
referenced appeared, along with several complaints by ld32, the linker,
to the effect that in some modules /usr/lib32/libXext.so is not used for
resolving any symbol. From past experience, the declared but unreferenced
variables are sometimes necessary for reasons external to the immediate
code.
The only other possibly serious error message I could see was a problem
with formatting an error message:
cc -c -O -DDO_NOT_HAVE_MALLOC store_handler.c
cc-1197 cc: WARNING File = store_handler.c, Line = 174
The indicated format string requires additional arguments.
sprintf(error_msg, "could not open '%s' for writing");
^
With the edits noted above, the build completed, and I was able to
run analysis.
In cleaning up after this build as well as builds on other systems, I note
that the file ccpnmr/ccpnmr1.0/c/memops/global/contour.c does not generate
a .o file and is not referenced in Makefile for that directory.
Sincerely,
--
Bruce D. Ray, Ph.D.
Associate Scientist, and Operations Director
NMR Center
IUPUI
Physics Dept.
402 N. Blackford St.
Indianapolis, IN 46202-3273
