This is a draft document I wrote to help people build open source software on IRIX. It may be missing some items but as someone who has built literally hundreds of packages on IRIX over the years I'm pretty confident that most of the pitfalls are covered.

General

IRIX has a very comprehensive Unix API. Not only it is POSIX and POSIX-2 compliant, it is also compliant with XOPEN XPG/4, SVID (SystemV R4), BSD extensions, Unix 95 (Spec 1170) and more.

Software that compiles on other Unix'es (notably those with a smaller API, like Linux and Free/Open/Net BSD), should, almost with no exceptions, compile and run smoothly on IRIX (but read on).

Still: there's way too much software out there that makes non-portable assumptions or written improperly, which may cause problems.

Here's an item list to save you time porting open source software to IRIX.

• GNU configure and autoconf
• Makefiles
• ranlib
• install
• BSD
• System types
• varargs
• Catching other problems
• SGI cc
• Multiple other problems (too many to list here)
• Build vs target env
• gcc vs cc

---

• GNU configure and autoconf

  GNU autoconf generates configure scripts which make the wrong assumption that if a library exists, it should be used. This is incorrect on IRIX which keeps some old libraries around just for the sake of backward compatibility with very old programs. This alone breaks most of the GNU utilities on IRIX. To prevent this from happening, simply force GNU configure to explicitly ignore 'libsocket', 'libnsl', 'libgen', and 'libsun'. All these interfaces have their up-to-date entries in the standard C library libc.so on IRIX 6.x.

  i.e, when calling GNU configure, you should use something like:

  	ac_cv_lib_gen_getmntent=no \
  	ac_cv_lib_sun=no \
          ac_cv_lib_sun_getpwnam=no \
  	ac_cv_lib_sun_getmntent=no \
          ac_cv_lib_sun_yp_match=no \
          ac_cv_lib_socket=no \
  	ac_cv_lib_socket_main=no \
  		configure ...
  

  Note that this is just an example, make sure to look at your config.cache (or equivalent) file after configuration, inspect it for any suspicious ac_cv_lib... entries that match one of the libraries mentioned above and set them to no (or equivalent).

• Makefiles

  Some open source programs assume GNU make in their Makefiles I always use GNU make on IRIX. Compatibility is good. With GNU make supporting parallel makes there's really no reason to use any IRIX specific make like smake/pmake/make.

  If you don't have GNU make for IRIX, you may download it from http://freeware.sgi.com/ and you don't need to worry about Makefile portability anymore.

• ranlib

  An historical BSD thing that should have been done by the linker transparently anyway. You don't need this in IRIX. If you Makefile calls ranlib either delete this or define it to a no-op.

  	gmake RANLIB=:  ...
  

• install

  The Berkeley 'install' is incompatible with the SYSV install either upgrade to IRIX 6.5 (where the IRIX install has transparent BSD compatibility) or define:

  	gmake INSTALL=bsdinst  ...

• BSD

  BSD programs that assume a BSD environment should compile on IRIX without change (well at least in 95% of cases) by forcing BSD compatibility via CFLAGS, e.g:

  	gmake CFLAGS="-D_BSD_COMPAT ..."

  If you don't want full BSD compatibility, consider using one or more of:

  	-D_BSD_TYPES
  	-D_BSD_TIME
  	-D_BSD_SIGNALS
  

  Important: if your software is more "properly" written and uses POSIX signals (i.e. sigaction instead of signal) then you should not compile with -D_BSD_SIGNALS. Mixing signal models may cause unpredictable problems.

• System types

  Some programs assume system types, in particular 'off_t' are 32 bit (files don't exceed 4GB in size)
  These programs are buggy in their assumption but this problem can be overcome by compiling in the o32 (cc -32) ABI:

  	gmake CC="cc -32 ..."
  

• varargs

  Some programs do not comply with the ANSI varargs syntax and conventions (i.e. include <stdarg.h> and use ellipsis in the argument list) Again, if those don't work they may start working by compiling using the o32 ABI:

  	gmake CC="cc -32 ..."
  

• Catching other problems

  The SGI cc is verbose and pedantic. The problem is that when you get way too may warnings you start ignoring the real ones.

  To make the SGI compiler more like gcc in terms of warnings you may use something like:

  	NOWARN = -woff 1009,1014,1048,1110,1116,1185,1188,1204,1230,1233 \
          	-Wl,-woff,85,-woff,84
  	$(CC) $(NOWARN) ...

  In your Makefiles

• SGI cc

  While the SGI cc may look too pedantic, it can catch a lot of real source code bugs. Consider compiling with:

  	CC="cc -fullwarn ..."
  

  and really clean your source from type mismatches.

• Multiple other problems (too many to list here)

  Over the years IRIX got thousands of bug fixes. As expected, problems on IRIX 4.0.x are way more numerous than problems on IRIX 6.5. If you can upgrade, please do. Life is way easier with IRIX 6.5.

• Build vs target env

  Virtually all open source packages assume that the building environment is the same as the target environment. In fact every Makefile with a 'make install' that directly installs into system directories probably makes this assumption. IRIX supports a much more elegant model of 'inst'able packages that can be built anywhere and installed anywhere else.

  I wish there was a Unix wide standard for this (Red Hat RPM and other Linux installers are getting there which is great)

  I usually build open source software with an IRIX 6.2 ROOT (i.e. get include files and libraries from a backward compatible 6.2 mounted directory. Assuming this directory is called /6.2_root - this is done by:

  	cc -nostdinc -I. -I/6.2_root/usr/include ...	(compiling)
  	cc -nostdlib -L/6.2_root/usr/lib32 ...		(linking)
  

  This way even though I build on IRIX 6.5 with the latest compilers I get full binary compatibility with IRIX 6.2 and up.

  The packaging itself is an art form. At SGI we use a specialized 'install' perl script to intercept calls from 'make install'. This 'install' adds the appropriate lines to the 'idb' file instead of actually installing files. Later, this idb file is used by 'gendist' to create the packages. Unfortunately, way too many open source packages are calling 'mv, cp,' etc. etc. to install so they are bypassing this mechanism. An idea that was not implemented here yet is to intercept system calls like 'mkdir' 'rename' and 'open' by faking LD_LIBRARYN2_PATH before calling make install. If you ever do this, please let me know.

• gcc vs cc

  Code that runs fine when compiled withe SGI cc and doesn't run when compiled with gcc is possibly using calls to one of the following:

  	inet_ntoa, (and some other inet_XXX), semctl
  

  (there may be others). These are functions that get passed or return structs that are smaller than 16-bit long and not 8-bits long. gcc and SGI cc are incompatible in the way they pass these structs so compiling with gcc and linking with the SGI libc.so (which was compiled with the SGI cc) is likely to cause these problems. Note that this problem is pretty rare since such functions are not widely used. This may be considered a bug in gcc but is too involved to fix I'm told.

---

Additions and contributions to this list will be gratefully accepted.
ariel@engr.sgi.com

---