Hello,
Thanks for all that. Our compilers (Mac + Linux) are obviously much worse
(in default mode) than yours since they didn't trap those silly errors
(but those silly errors don't make a difference at runtime (except the
one with the error message would give a wonky message). I've added the
five updated files to the update server, if anyone wants to update (you
also need to do "make" in ccpnmr1.0/c then).
Can you send me the installation log file when you try running
installCode.py, and also the environment.txt it is creating (i.e. before
you edited it). I had hoped that the lib/lib32/lib64 saga was getting
closer to resolution but it seems not! (Or is it that with some SGIs the
libraries are in lib and with some they are in lib32 and that both
directories exist on some machines?? Or do they both always exist on all
SGIs because of n32/o32??)
Thanks, Wayne
On Fri, 17 Nov 2006, Bruce D. Ray wrote:
> 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
>
|