What We Did to Port the Developer Toolbox to IRIX 6.2 and, What We Learned About In The Process Chapter 1 ------------------------------------------------------------- This document is a record of everything we did to upgrade and then re-compile the DT on IRIX 6.2 with the "bare-bones" o32 option. Table of Contents 1. Upgrading the DT machine 2. The Challenge of n32 3. o32 and n32 Pointers References 4. What DT Source Code Changed o Major Upgrades o Minor Upgrades o Included But Not Ported to IRIX 6.2 o NOTES The reason this is "Chapter 1" is because we have not yet succeeded in cleaning up DT source code so it is n32 capable. By so doing, one can attain full access to 64-bit wide integer registers and 64-bit instructions in a 32-bit address space. It is the janitor's understanding that achieving such n32 "code robustness" is the developer's most basic and significant undertaking in moving to IRIX 6.2 from an IRIX 5 universe. Some of the relevant details about this are described in section 2, The Challenge of n32. ------------------------------------------------------------- Upgrading the DT machine -------------------------------------- The toolbox source, build, test and SGI-internal-website machine, named dtdustbin and aliased as "swank", is an IP19 6-processor Challenge-L system. In May, we upgraded swank from IRIX 5.3 to 6.2, changing the 2GB system disk to be an xfs filesystem in the process. Since the IP19 is 64-bit, we went thru the kernel upgrade from 32-bit without a hitch. We chose to switch our system to be xfs in anticipation of taking advantage in the future of creating a single LARGE "filesystem" by combining our series of 4-GIG disks to operate as a single partition. Prior to re-compiling the DT, we pass on a few tidbits of what we learned while upgrading swank. 1. Choose "delay resolving conflicts" when inst'ing the "IRIX 6.2TM (Part 1 of 2)" CD documentation on this issue is not revealing itself so, from memory, this is the best that can be provided here: in upgrading to IRIX 6.2 with the two CDs labeled, "IRIX 6.2TM (Part 1 of 2)" and "IRIX 6.2TM (Part 2 of 2)", once you have made all the selections you want on the first (Part 1 of 2) CD, somewhere before or after typing "go" at the Inst> prompt, one is presented with two choices that say something like: 1. resolve conflicts now 2. delay resolving conflicts DON'T FALL INTO THE TRAP the silly janitor did of selecting number 1. never having seen this before, he was not aware of the fact that there would be a barrage of conflicts that would not be resolved since one needs to install BOTH Parts 1 AND 2 before outstanding conflicts are resolved. The alternative to selecting number 2 above is to turn the delay_conflicts Inst Preference to "on". Stepping into Inst and typing the command Inst> set delay_conflicts reveals such information as "Controls when certain "delayable" conflicts are presented to the user. . . . In some installation scenarios, the conflict will have to be delayed since the subsystem(s) necessary to resolve the conflict are not on the current distribution. . . . An `on' value will always present the delayable conflicts prior to exiting." This is precisely the case when the baseline eoe distribution spans 2 CDs as it does for IRIX 6.2. See "IRIX 6.2 Instructions for Customers Updating From Earlier IRIX Releases" (toolbox/documents/irix6.2/6.2errata.ps.Z), for more information. If for some reason you find yourself forced to take choice number 1, remember that all the defaults you had for any selected products that end up being removed are lost, so be sure to scan the choices carefully. In particular, do NOT do "keep N," or the system will be barely, or not at all, usable. For a listing of what products exist on the IRIX 6.2TM (Part 1 of 2) CD, see the section by the same name in the "IRIX 6.2 for System and Network Administrators" Pipeline article. Likewise for IRIX 6.2TM (Part 2 of 2). 2. 6.2 depends on IL 2.5.1 -- DON'T attempt to load/use IL 3.0 on IRIX 6.2 the janitor learned from one of the Image Library (IL) gauds in engineering that IRIX 6.2 depends on IL 2.5.1. he had mistakenly updated to IL 3.0 since that version was what existed in the 6.2/all directory of inst images on the SGI internal dist machine. with IL 3.0, applications like toolbox/src/ibrowse and toolbox/src/exampleCode/movies/cineswipe/libcineswipe failed to compile, producing Errors of the kind, #error This header file is obsolete, use or define IL2_5_COMPAT -- but even defining IL2_5_COMPAT in the Makefile did not resolve the errors. that's when we learned that 3.0 is not the IL meant to be used with IRIX 6.2. we got back on track by doing a versions remove il_eoe il_dev as root, and then installing the 2.5.1 version. after this, everything once again worked without any barking from the compiler. 3. one only needs 4 subsystems from the 2.0.1 performer_dev.sw image the janitor learned from one of the Performer gauds in engineering that of the performer_dev.sw image, the only subsystems needed to do basic compilations of performer code are: 1. performer_dev.sw.hdr 2. performer_dev.sw.common_performer 3. performer_dev.sw.ogl_performer 4. performer_dev.sw.igl_performer The Challenge of n32 ------------------------------- Prior to creating the necessary porting environment by explicitly specifying the /usr/lib32 n32 library location (see N32 Porting Guidelines from the MIPSpro(TM) N32 ABI Handbook), the janitor faces the fact that a great deal of code currently resident on the DT needs loads of ANSI "polish" applied to it before it is ready for the successful jump to n32. We did perform one "trial pass" of the toolbox/src subtree with -n32 activated. To do this we conferred with the make/commondefs/commonrules gaud in engineering who explained how to modify the IRIX 6.2 version of the /usr/include/make/releasedefs file (installed from the eoe.hdr.lib subsystem) so that instead of definining DEF_CSTYLE=$(CSTYLE_32_M2) DEF_GLDOPTS=$(GLDOPTS_32_M2) . . . DEF_OBJECT_STYLE=32_M2 DEF_32_OBJECT_STYLE=32_M2 we switched these to be DEF_CSTYLE=$(CSTYLE_N32_M3) DEF_GLDOPTS=$(GLDOPTS_N32_M3) . . . DEF_OBJECT_STYLE=N32_M3 DEF_32_OBJECT_STYLE=N32_M3 By doing this, we witnessed the IRIX 6.2 o32 "default compiler settings" -- using -mips2 -o32 compile lines of the form, //usr/bin/cc -fullwarn -I..//include -c -nostdinc -I//usr/include -mips2 -o32 -O -MDupdate Makedepend -woff 1685,515,608,658,799,803,852,1048,1233,1499 -c axes.c -- change to employ the -mips3 -n32 flag: //usr/bin/cc -fullwarn -I..//include -c -nostdinc -I//usr/include -mips3 -n32 -O -MDupdate Makedepend -woff 1685,515,608,658,799,803,852,1048,1233,1499 -c axes.c The results of this trial pass (running make -i >& makeLog to continue compilation past fatal errors) produced many errors which, under the o32 libraries did not even show up as warnings. One way of measuring the differing results of o32 and n32 in the toolbox/src subtree is that the files generated by redirecting STDOUT/STDERR were orders of magnitude different in size: * "makeLogO32.txt" 12401 lines, 781123 characters * "makeLogN32.txt" 271894 lines, 8644807 characters From this, we are looking at pursuing two parallel tracks in order to start providing n32-compiled binaries-from-DT-source come this fall: 1. Begin polishing selected programs in the current DT tree 2. Begin integrating new content that already compiles cleanly using n32 From 1 above, the requisite "polish" to create n32-compilable source will include such areas of attention as 1. resolving all errors produced by -fullwarn option of the kind o catastrophic error(1005): could not open source file "____" o error(1020): identifier "____" is undefined o error(1028): expression must have a constant value o error(1040): expected an identifier o error(1080): a storage class may not be specified here o error(1084): invalid combination of type specifiers o error(1118): cast to type "Matrix" is not allowed o error(1119): return value type does not match the function type o error(1164): argument of type "____" is incompatible with parameter of type "____" o error(1140): a value of type "____" cannot be used to initialize an entity of type "____" o error(1143): declaration is incompatible with o error(1153): declaration is incompatible with previous "____" o error(1238): member "____" is inaccessible o error(1250): invalid ____ declaration o error(1278): no instance of overloaded function o error(1287): const or volatile qualifier on this function is not allowed . . . o error(1332): base class name required -- "____" assumed o error(1361): delete array size expression ignored o error(1515): a value of type "____" cannot be assigned to an entity of type "____" o error(1563): expression must have pointer-to-class type 2. using function prototypes where they currently aren't being defined. It is critically important to be aware of this: some programs won't work correctly -- even if they compile -- if they don't have the prototypes in force, particular for varargs and math routines, but not restricted to those. Quoting from a relevant segment of the Native 64-Bit (N64) and N32 Subprogram Interface for MIPS Architectures section of Chapter 2: Calling Convention Implementations of the the MIPSpro(TM) N32 ABI Handbook: o Whenever possible, floating point arguments are passed in floating point registers regardless of whether they are preceded by integer parameters. [The 32-bit ABI allows only leading floating point (FP) arguments to be passed in FP registers; those coming after integer registers must be moved to integer registers.] o Variable argument routines require an exception to the previous rule. Any floating point parameters in the variable part of the argument list (leading or otherwise) are passed in integer registers. Several important cases are involved: + If a varargs prototype (or the actual definition of the callee) is available to the caller, it places floating point parameters directly in the integer register required, and no problems occur. + If no prototype is available to the caller for a direct call, the caller's parameter profile is provided in the object file (as are all global subprogram formal parameter profiles), and the linker (ld/rld) generates an error message if the linked entry point turns out to be a varargs routine. Note: If you add -TENV:varargs_prototypes=off to the compilation command line, the floating point parameters appear in both floating point registers and integer registers. This decreases the performance of not only varargs routines with floating point parameters, but also of any unprototyped routines that pass floating point parameters. The program compiles and executes correctly; however, a warning message about unprototyped varargs routines still is present. + If no prototype is available to the caller for an indirect call (that is, via a function pointer), the caller assumes that the callee is not a varargs routine and places floating point parameters in floating point registers (if the callee is varargs, it is not ANSI-conformant). 3. as time permits, resolving the massive amount of warning messages. Some of these warnings are due to SGI's header files (particularly those from the X and motif consortiums) not being truly ANSI-clean. Disabling those warnings with -woff gets rid of much of the "noise" at the cost of perhaps missing some potential problems in your own code. The janitor hopes you understand and appreciate the value and benefit running "make -i" is providing us in the errors the new compilers found in the DT code and that the "noise" produced is justified in that it finds real problems. Also recommended is employment of the compiler option -diag_error -- "The messages with the specified numbers are treated as errors. In particular, if any such message is reported, no object file will be generated" -- which can make specific warnings fatal, to ensure you don't get sloppy once you have clean things up (engineering groups inside SGI have done this on the kernel, and some other parts of the system). The process of cleaning up one's code often does find real and sometimes longstanding bugs. Obviously number 3 is a laudable goal, but in the actual, pragmatic world, will get short shrift with the passage of time. To compensate for this, we are also honing our information ferreting teeth for this fall, so that once we have completed spinning the v6.1 DT, we can actively begin to identify, locate, qualify, and integrate source that passes the "n32 compatibility test" with flying colors. After the release of v6.1 we will begin creation and population of an "N32-compliant apps on the DT" web page (initially it will show up in the NEW page, and, i'm sure, end up on the HOT page as well as in all the appropriate global (topical, A-Z Documents) file listings). As an aside, for those who would like to know what commands are n32 on IRIX 6.2, look for the following output from file(1): /bin/sh: ELF N32 MSB mips-3 executable MIPS - version 1 Other "n32 graduates" include: csh, ksh, and rqs32. o32 and n32 Pointers ------------------------------- To be precise: Our Goal in all this is the following: If you support R4000 platforms on IRIX 6.X, you will want to compile -n32 -mips3. This gives you the compiler improvements of newer compiler optimization technology without converting your pointers to 64-bit. If you are supporting mips4 platforms and want to tune for those systems, then compile -mips4 [-64] (if you have checked your code for 64-bitness add -64). This will limit the systems that can run -mips4 (R4000 is mips3) but should give your code a boost. For some of the salient information on the o32 and n32 ABI implementations in IRIX 6.2, see * Preparing for IRIX 6.2 & 64-bit, A Nutshell view and series of pointers * The Next Generation of Compiler Technology, Developer News, 5/96 * Accessing 64-bit CPU Power with 32-bit Software, Developer News, 5/96 * ABI Attribute Summary the o32 and n32/64-bit ABI implementations.[1] * Example Application illustrates steps necessary to port from o32 to n32.[2] * N32 Porting Guidelines -- steps necessary to port IRIX 5.x 32-bit apps to n32. [3] * What is N32? -- describes the n32 ABI and compares it with the other MIPS ABIs. [4] * The Compiler Information section from the Welcome to IRIX 6.2 document * IRIX 6.2 Application Binary Options from IRIX 6.2 Technical Report * Obsoleted Hardware IRIX 6.2 does not support the following systems and peripherals: o R2000/R3000 systems o GTX graphics on a Crimson system o IPI, SMD, and ESDI disk drives o Xylogics (XM) 1/2 Inch tape drives o Ikon Board o svideo option on Indigo _________________________ References 1. MIPSpro(TM) N32 ABI Handbook, Chapter 2: Calling Convention Implementations 2. Ibid, Chapter 4: N32 Examples and Case Studies 3. Ibid, Chapter 3: N32 Compatibility, Porting, and Assembly Language Programming Issues 4. Ibid, Contents of This Guide What DT Source Code Changed ------------------------------------------ MAJOR UPGRADES: ----------------------------------------------------------- * toolbox/src/tutorials/custEducation/opengl1/ * toolbox/src/tutorials/custEducation/opengl2/ Major changes/shuffles -- see toolbox/src/tutorials/custEducation/opengl1/Release_Notes and opengl2/Release_Notes for more details -- use of libaux and libtk has been replaced with a new utility toolkit, liboglprog so the below directory name changes do NOT adequately reflect the changes occuring within all other directories whose names haven't changed. opengl1: DELETED: demos/OGLPG{/libaux,/libtk}/ demos/Mixed_Model/ examples/antialiasing/ examples/input/ examples/light_properties/ ADDED: examples/dlists/ opengl2: DELETED: examples/clipping/ examples/dlists/ examples/extensions/ examples/re_extensions/ librgb/ ADDED: demos/Tutorials/ examples/adv_texture/ examples/clipplanes/ examples/image_extensions/ examples/sgi_extensions/ RENAMED: examples/raster/ --> examples/rasterops/ examples/stencils/ --> examples/stencil/ labs/raster/ --> labs/rasterops/ MINOR UPGRADES: ----------------------------------------------------------- * toolbox/public/TIFF/tools/ Removed archaic _s from -lgl and -lc in Makefile, Makefile.sgi, Makefile.aix, and Makefile.sco, since there are no longer even the stubs (as there was in IRIX 5) for "shared libraries" in IRIX 6 which used to exist in IRIX 4 (e.g. -lgl_s). * toolbox/src/demos/GL/demograph/ Removed -lmalloc since mallopt is not called [2] * toolbox/src/demos/GL/flight/ Removed -lmalloc since mallopt is not called [2] * toolbox/src/demos/GL/libdemo/ Updated percentDone.c++ to the IRIX 6.2 version in the engineering src tree * toolbox/src/demos/audio/bz/ Removed -lmalloc since mallopt is not called [2] Removed redundant -lc from load-link line * toolbox/src/demos/OpenGL/insect/ Moved src/demos/OpenGL/libtk into insect as this is the only ogl demo still using it (everything else is converted to libglut now or straight ogl libs). Deleted the U__EXTENSIONS__ def from libtk's Makefile. * toolbox/src/demos/OpenGL/space/ * toolbox/src/exampleCode/GLX/cutNpaste/Motif+Xt/ * toolbox/src/exampleCode/GLX/dualhead/ * toolbox/src/exampleCode/GLX/rubberband/ * toolbox/src/exampleCode/GLX/texvol/ Removed -lmalloc since mallopt is not called [2] * toolbox/src/exampleCode/MP/timer/highres/ Replaced #include with #include * toolbox/src/exampleCode/SciTex/examples/phong/ Removed -lmalloc since mallopt is not called [2] Removed -lfm -lsphere since "not used for resolving any symbol" * toolbox/src/exampleCode/audio/DAT/ cdtodat.c and dodat.c: strncmp() was being used without a third (size) args; thus changed strncmp() to strcmp() representative error was: cfe: Error: cdtodat.c, line 589: The number of arguments doesn't agree with the number in the declaration. if (argc == 2 && !strncmp(argv[1],"-q")) { -----------------------------^ * toolbox/src/exampleCode/audio/somePlayback/ Removed -lmalloc since mallopt is not called [2] * toolbox/src/exampleCode/audio/sonic/ [5] Many loader errors of the following kind: ld: ERROR 33: Unresolved text symbol "endqstrip" -- 1st referenced by //usr/lib/libsphere.a(sphere.o). solution was to move libsphere in front of libgl in the Makefile * toolbox/src/exampleCode/games/IndiZone/blix/ Changed {blixscore_io.c,blixscore.c,blixmenu.c,blix.c} -- which all used an explicit prototype definition at the top of each file, int sginap(long); that is not required, and in fact erroneous, in irix 6.2. Representative error was: redeclaration of 'sginap'; previous declaration at line 427 in file '//usr/include/unistd.h' * toolbox/src/exampleCode/games/IndiZone/sw/ Changed 2 lines in main() in serv_comm.c++ signal(SIGINT, terminate_server); // let user kill server signal(SIGTERM, terminate_server); // let user kill server to be signal(SIGINT, (SIG_PF)terminate_server); // let user kill server signal(SIGTERM, (SIG_PF)terminate_server); // let user kill server Explanation: /usr/include/sys/signal.h which signal.h has: #ifndef __sigret_t #define __sigret_t void #endif typedef __sigret_t (*SIG_PF) (__sigargs); -- this magic enables the casting of terminate_server to be the correct type. ALSO, changed sound.c++ where the last two args of AFgetsampfmt(f, AF_DEFAULT_TRACK, &fmt, &width) were being defined as int and have now been changed to be long. * toolbox/src/exampleCode/i18n/ Removed libw.a and libgen.a from the Makefile -- the full functionality is now in libc * toolbox/src/exampleCode/inventor/noodle/ MANY different kinds of errors were being generated revolving around incompatibilities between int <--> long which no longer just produces warnings (e.g., '"SoMFInt32 *" cannot be used to initialize an entity of type "SoMFLong *"'). Solution was that we changed {GeneralizedCylinder.c++,LineManipHilight.c++,Triangulator.{c++,h}}: SoMFLong --> SoMFInt32 int long ... --> int32_t ... long --> int32_t and added: #include "" * toolbox/src/exampleCode/inventor/soundspheres/ deleted the following libs -- -lgutil -lfm -limage -lgl -lmpc -- no longer used, and replaced mismatched ints with longs * toolbox/src/exampleCode/movies/cineswipe/ [3] Added #include to libcineswipe/cosmo_capture.c ALSO fixed an old bug in cineui/cineui.c++ -- from the author: "only a bug in the sense that i intended it to save in one compression format but accidentally forgot to initialize that to be the default so it instead set it to that movie lib internal format (which is currently unsupported in 6.2). Actually this is better now since it's doing what i first intended." added 3 new lines add starting at line 201: controls->outType = outputInfo[0].type; strcpy(controls->movieParms.compType, outputInfo[0].comptype); controls->movieParms.mvFileFormat = outputInfo[0].filetype; * toolbox/src/exampleCode/networking/HIPPI/ Added #include to blast.c to resolve the error of "'CLK_TCK' undefined" * toolbox/src/exampleCode/networking/rpcdemo/ rm_svcproc.c was generating errors of "'_PAGESZ' undefined" centering around the prior use of ctob(). The fix was that the ctob() macro converts "clicks" to bytes but since a "click" is a page the getpagesize() routine is the way to do it. also deleted librpcsvc -- apparently all its functionality is now incorporated inside libc. * toolbox/src/exampleCode/opengl/2Dwrap/ogl/ [5] Moved -lGLw to the beginning of the LLDLIBS line to resolve errors of the kind: ld: ERROR 33: Unresolved text symbol "glXChooseVisual" -- 1st referenced by //usr/lib/libGLw.a(GLwMDrawA.o). * toolbox/src/exampleCode/opengl/GLUT/test/ Added -lm at the end of the Makefile's LLDLIBS line [1] * toolbox/src/exampleCode/opengl/cap/ [5] Moved -lGLw to the beginning of the LLDLIBS line to resolve errors of the kind: ld: ERROR 33: Unresolved text symbol "XtWidgetToApplicationContext" -- 1st referenced by //usr/lib/libGLw.a(GLwMDrawA.o). * toolbox/src/exampleCode/opengl/colorChooser/ [5] Moved -lGLw to the beginning of the LLDLIBS line to resolve errors of the kind: ld: ERROR 33: Unresolved text symbol "XCreateColormap" -- 1st referenced by //usr/lib/libGLw.a(GLwMDrawA.o). * toolbox/src/exampleCode/opengl/defrasterPort/ [5] Moved -lGLw to the beginning of the LLDLIBS line to resolve errors of the kind: ld: ERROR 33: Unresolved text symbol "glXChooseVisual" -- 1st referenced by /usr/lib/libGLw.a(GLwMDrawA.o). * toolbox/src/exampleCode/opengl/glx/ Removed libXnmbx.a and libXmu.so -- no-longer needed and moved util.o to immediately follow the program files themselves on the load/link line. * toolbox/src/exampleCode/opengl/lmwrap/igl/ Removed -lmalloc (since mallopt is not called) [2], and moved -lsphere in front of -lgl to resolve the raft of errors [5] of the kind, ld: ERROR 33: Unresolved text symbol "translate" -- 1st referenced by //usr/lib/libsphere.a(sphere.o). * toolbox/src/exampleCode/opengl/lmwrap/igl/ Removed -lmalloc (since mallopt is not called) [2], and moved -lGLw in front of -lGL to resolve errors [5] of the kind, ld: ERROR 33: Unresolved text symbol "glXChooseVisual" -- 1st referenced by //usr/lib/libGLw.a(GLwMDrawA.o). * toolbox/src/exampleCode/opengl/motif/ Removed the U__EXTENSIONS__ def from the Makefile to resolve the errors, cfe: Error: //usr/include/stdlib.h, line 235: Syntax Error extern void swab(const void *, void *, ssize_t); ---------------------------------------^ Removed -lSgm and moved -lGLw to the front of drawWidget's load-link line and removed -lGLw from textfun's load-link line * toolbox/src/exampleCode/opengl/render2pixmap/ Removed libXnmbx.a and libXmu.so as they are no longer used to resolve any symbols; moved util.o to the beginning of the LLDLIBS to resolve the rafts of errors [5] of the kind, ld: ERROR 33: Unresolved text symbol "XOpenDisplay" -- 1st referenced by util.o. * toolbox/src/exampleCode/opengl/x+opengl/ Had to remove the renderboth.c file/program which uses the now obsolete double-buffering calls from libXnmbx.a which, we learned, is now replaced by the new X Consortium standard again, DBE(3X11) (double-buffering extension). The DBE man page is in the x_dev.man.mandev subsystem. As was told to the janitor by one of the X gauds in engineering, . . . you should use the new X Consortium standard, DBE. However, there is still no official replacement for the NMBX calls dealing with queries for framebuffer capabilities, which is why there still is an NMBX library shipped. This is discussed in the x_dev release notes (although the part about framebuffer capabilities still being supported could have been made clearer). * toolbox/src/exampleCode/stereo/opengl/ removed -lSgt and -lgutil from Makefile -- both are no longer needed/used * toolbox/src/haeberli/ibrowse/ [3] Added #include to ibrowse.c * toolbox/src/haeberli/imgtools/ [1] Added -lm to Makefile compile rules for iv and tosgi * toolbox/src/tutorials/custEducation/openInventor/ Replaced the index[4] array type declaration in text/fancyText3.c++ from long to int. Error generated was, "fancyText3.c++", line 83: error(3346): function "SoMFInt32::setValues(int, int, const long *)" is inaccessible lp->index.setValues(0, 4, index); DELETED: ----------------------------------------------------------- * toolbox/bin/games/blackbox/ We were not able to successfully recompile this and were unable to contact the author to see if he has already ported it to IRIX 6.2 * toolbox/src/exampleCode/X/motif/ Removed this subtree for the present -- the only thing in it was the overlays example subdir. Its author was too backed-up to revamp it now but hopes to be able to get back to this this fall. * toolbox/src/exampleCode/opengl/samples/ Removed this subtree as this is now part of the gl_dev.sw.samples subsystem in irix6.2 and, although we would have liked to have included these in the this version of the toolbox as well, we did not have the time to do so. INCLUDED BUT NOT PORTED TO IRIX 6.2: ----------------------------------------------------------- (we still include the src for people on IRIX 5, as well as the possibility of more collaboration between the janitor and all of you [4].) * toolbox/hardware/rap/ Currently the RAP driver is not ported for IRIX 6.2 (64-bit int size) so we were not able to include a compiled version in this release. The error returned was, cfe: Error: //usr/include/sys/sbd.h, line 80: Syntax Error <> * toolbox/src/demos/GL/buttonfly/ We were unsuccessful in recompiling buttonfly on IRIX 6.2 with the -fullwarn option. Without -fullwarn this program does compile, however although we are only working with o32 at the current time, we are committed to performing all the code checking we can to "smoke out" and identify the "worst offenders". In this sort of context, buttonfly fails and we are including it as such in the "INCLUDED BUT NOT PORTED TO IRIX 6.2" category. * toolbox/src/exampleCode/inventor/DirectManipRevoSurf/ From the author who was time-strapped: RevoSurfEngine dso doesn't load so the program is essentially useless. I think it has to do with how the .so file is being made. I'm using ld instead of CC or something but I don't know the solution. At this point, the dso is able to be compiled, but runtime fails with: % setenv LD_LIBRARY_PATH . % ivview -q test.iv Inventor read error: Unknown class "RevoSurfEngine" Occurred at line 74 in ./test.iv * toolbox/src/exampleCode/opengl/GLR/glrduck/ The IRIX 6.2 GLR library is not available at this time. We hope to have inst images available with the v6.2 DT releasing at the end of this calendar year. Please stay tuned to the location: https://www.sgi.com/toolbox/src/exampleCode/opengl/GLR/ Once we have the software onboard, we'll indicate its presence and location on this page. * toolbox/src/exampleCode/opengl/GLUT/progs/fortran/ This one was very strange: we were seeing boatloads of errors throughout this directory attempting to compile with libfGL.a (since all the OpenGL Fortran programs in the DT live here) of the form, ld: ERROR 33: Unresolved data symbol "glBindTexture" -- 1st referenced by /usr/lib/libfGL.a(libfogl32.o). These unresolved symbols are OpenGL 1.1 entry points, and we don't support 1.1 yet. It turns out that libfGL.a has 1.1 bindings, and all wrappers are in a single object file. The ramification is that calling any fGL routine pulls in wrappers for all entry points, including the the 1.1 versions of the extensions. Thus, any program which links with libfGL.a will have the unresolved symbols you encountered. There are two possible workarounds to this problem. 1. If you add "-Wl,-U" to the link line (or just "-U" if you invoke ld directly) you will get an executable. You then must setenv _RLD_ARGS -ignore_unresolved to run the executable. 2. You can create a stubs file to resolve the missing entry points. They will (should) never be called, so all it does is make the linker happy. For the present, we include the source for people still running IRIX 5, but for those with IRIX 6, you will have to resort to one of the above hacks if you want to attempt compiles on OpenGL using fortran. * toolbox/src/exampleCode/opengl/oat/src/ The janitor is not well-versed in C++ nor Inventor and the author of oat was unavailable, so while this program's source is still included, there is no binary. * toolbox/src/exampleCode/speech/ The speech software hit a roadblock in IRIX 6. It is with regret that at the current time resources in engineering are so tight that the speech project is currently on hold while the engineer who was dedicated to speech development has been pulled off onto another project. If this impasse impacts your own development, please send email, describing your concerns and your interest in resuscitating the speech project's software in the IRIX 6 ocean, to DTjanitor@sgi.com", and we will pass all such correspondence on to the powers-that-be in software engineering who are responsible for such decisions. * toolbox/src/swtools/libdmalloc/ The author of libdmalloc was unavailable, so while this program's source is still included, there are no .a archives or .so dsos included. NOTES: ----------------------------------------------------------- 1. While the math library used to be automatically included whenever -lgl or -lX11 was invoked, that is no longer the case in irix 6.2. Now -lm must be explicitly included wherever math functions are employed. 2. The explicit use of libmalloc rather than the malloc inside libc now produces rafts of errors of the order: ld: WARNING 85: definition of realloc in //lib/libmalloc.so preempts that definition in //usr/lib/libc.so. A question the janitor had was, is there any "general rule" to follow re: if program is using an explicit -lmalloc in the LLDLIBS definition in the Makefile, is it now "acceptable"/"proper"/"advisable" to get rid of said explicit definition in 6.2 and give same unto libc? and answers included, o In general people are finding (as of IRIX 5.3) that libc's malloc is as good or better than libmalloc. So which is better depends on your application. Unless the app calls mallopt, you can probably just drop -lmalloc. o The libc malloc is the general ANSI malloc routines. libmalloc.so is higher performance vendor specific malloc routines. (At least in our case they are SGI specific). o At least for most cases, it has been advisable to remove libmalloc since 5.3. Does this mean libc memory allocation routines are the same as those in libmalloc under 6.2? (This was never the case before.) Not the same, but much improved over the 4.x versions. Either the SVR4 code was better, or we fixed it locally to improve performance in general. I remember some horror stories about the 4.x malloc, especially related to motif. In 5.3 people found it went the other way - libc malloc was usually "better" than libmalloc. Again, YMMV. 3. In order for all Image Library programs on the toolbox to successfully compile on IRIX 6.2, one MUST BE SURE one is using the 2.5.1 version of the il_eoe and il_dev products. Attempting to use the 3.0 versions of the Image Libraries will not work as the janitor discovered. 2.5.1 is THE version of the IL that is compatible with and intended for irix 6.2. 4. Pursuing our goal of extending collaboration between the DTjanitor and everyone in the Developer Program, while we were not able to port/successfully recompile these programs to/on IRIX 6.2, we nevertheless include their source so that, if anyone of you has the saavy, and finds the inclination/motivation enabling you to succeed in reviving these programs, PLEEZE send us whatever files (source, Makefile, etc.) you modify to "make it go" again, and we will add these back into the v6.2 DT release as working-again src+binaries. 5. Artifact of the "one-pass linker" produces errors of the form: ld: ERROR 33: Unresolved text symbol ..... using the example of src/exampleCode/audio/sonic/ above, since libsphere makes function calls which are resolved by libgl, you need to switch the order of those two libs on the link line. This is an artifact of the "one-pass linker": since the symbols are 1st referenced by libsphere, they were not resolved when the linker processed libgl, where the symbols are defined but not referenced.