4.42 Release Notes for SGI IRIX Computers

Back to 4.42 Release Notes.
15 Feb 1994


  APPENDIX: IRIX4 Compatibility With IRIX5



The following shell scripts are provided to run XView programs under SGI's
default "4dwm" window manager;


This scripts are supported but are no longer absolutely required.  Changes
to the Daylight "Options Manager" system allows automatic adjustment of
options which are window-environment specific (details below).  In most
cases, the user environment can be arranged so that these scripts are not
needed.  You may safely stop using the "4d" scripts under these conditions:

   o  you are not using SGI's default "4dwm" window manager, OR
   o  your client programs are running on an IRIX operating system, OR
   o  you have set the environment variable DY_WINDOW_ENVIRONMENT to SGI_4DWM


   o  you are willing to set your default font as described below.

If you stop using the "4d" scripts, you must add a line similar to this to
your X Resources database (i.e. to the file $HOME/.Xdefaults):

   Font.Name: -adobe-helvetica-medium-r-normal--14-100-100-100-p-76-iso8859-1

Without this specified, XView programs will work correctly, but fonts used
for titles and buttons may be big and ugly.  This normally takes effect when
you start X-Windows.  To make this change effective immediately, enter:

   $ xrdb $HOME/.Xdefaults

An example .Xdefaults that contains this line can be found in


   A bug in the IRIX X Window system combined with bad habits in Sun's XView
   code caused the IRIX window system to "lock up" when Daylight applications
   were run.  In addition, many of the default options (such as fonts, and
   graphics parameters) had to be changed for optimum performance when running
   under SGI's default window manager "4dwm".

   To solve this, Daylight supplies a set of "wrapper" scripts, "xvmerlin4d",
   "xvthor4d", and "xvpcmodels4d", that invokes XView programs with parameters
   appropriate for use with IRIX X-servers and the 4dwm window manager.

With release 4.33 and later ...

   These features are added to the Daylight "Options Manager" package:

   1. A new "#if/#else/#endif" feature was added to the Daylight options
      manager.  This allows selective processing of options.

   2. If the environment variable DY_OPERATINGSYSTEM is not defined at
      runtime, the Daylight options manager will automatically set it to
      the client's operating system (e.g., "IRIX", "SunOS", "HP-UX").

   3. A new version of dy_sysprofile.dat is provided as a suggested
      system profile.  This file uses the new "#if" feature to set up
      O/S- and window-specific options from environment variables
      environments are provided: SGI_4D, HP_VUE, MAC_X, and SUN_OLWM.

      The file dy_sysprofile.dat sets default SGI_4D option values for IRIX
      operating systems, HP_VUE values for HP-UX, SUN_OLWM values for SunOS.
      These values will be overridden if the DY_WINDOW_ENVIRONMENT variable
      is defined.  The MAC_X environment must be specified when needed.



Daylight software runs on version 4.0.5A and 4.0.5F, and under 5.1.2 or
later.  Pre-4.0.5 versions, and versions B-E of 4.0.5, are not recommended.

To find out what version you are running, use:

   % uname -r

If it prints "4.0.5", that is version 4.0.5A.  However, there are at least
two versions called 4.0.5A (so what's a version?), and you may get "4.0.5A".
Other versions of 4.0.5 always print a suffix [B-F].

Daylight Toolkit customers must be sure they have the rev. 3.10 SGI FORTRAN
and/or C compilers.  The SGI compilers have a separate release schedule and
numbering system.  Because of SGI's marketing strategy, you may have received
the 4.0.5 operating system, but NOT received the version 3.10 compilers.

To see what version of the compilers you have, use the versions(1) command
and look for the 3.10 Maintenance line:

   % versions | grep 'Ansi C'
   I  c                    08/21/91  Ansi C 1.1
   I  c.man                08/21/91  Ansi C Manual Pages
   I  maint_c              09/07/92  Ansi C Maint, 3.10

   % versions | grep Fortran
   I  eoe1.sw.lib          10/30/92  Execution C/Fortran Libraries
   I  ftn                  03/05/92  Fortran 77, 3.4.1
   I  maint_ftn            09/07/92  Fortran 77 Maint, 3.10



If you install the Daylight Toolkits on an IRIX 5.x system, you should be
aware of object-code incompatibility between IRIX 4.x and IRIX 5.x.

SGI has once again changed its object code (.o) file format.  Code compiled
under IRIX 4.x can't be linked to code compiled under IRIX 5.1 or later.
Because many customers have third-party libraries (such as UniPress XView)
that were compiled under IRIX 4.x, SGI has provided a "compatibility mode"
for its compilers: You can use the IRIX 5.x compilers to produce IRIX 4.x
object code.

If you need to use the "compatibility mode" to generate IRIX 4 binaries,
you can install the IRIX 4 version of the Daylight libraries on your IRIX
5.x system.  To do this, re-run the "dayinstall441" program; on the "SELECT
O/S ARCHITECTURE" screen, choose number 3, "IRIX 4.x", then when you get to
the "SELECT PRODUCTS" screen, choose option "f", the "Toolkit Programming

For more information about SGI object code, see "APPENDIX: IRIX4
Compatibility With IRIX5" at the end of this file.



(This procedure is not usually necessary on IRIX 5.x systems.  SGI has
changed the IRIX kernel's default configuration to the configuration
described here.)

The Problem:

   The SGI IRIX kernel gives out more memory than it actually has, on the
   theory that many programs never use all of the memory they ask for.  This
   feature is used by some graphics programs which allocate high-dimensional
   arrays that are nearly empty -- the allocated space is never used.

   If several programs ask for lots of memory, the kernel can pretend to give
   them all what they ask for even though it doesn't really have it.  However,
   if these programs ever use all the memory they are given (i.e. if the
   actual memory use exceeds the total memory plus swap space), the kernel
   "panics" and starts killing processes.

   This means, for example, that a Merlin server that has been running
   without problems for days can be killed because a DIFFERENT process is

   The Merlin server is carefully designed to not crash when it runs out of
   memory.  When it asks the kernel for memory, it trusts the kernel to give
   it real memory or to tell it "no".  For example, if you try to create a
   column, it simply reports failure; if more memory becomes available, a
   later request for column creation will succeed.

   Using the default configuration of the IRIX system, the Merlin server
   can't tell whether the memory it is given is really there or not.  This
   makes the default kernel shipped with SGI IRIX computers unsuitable for
   use as a database server.

The Solution:

   An operating system parameter can be configured to make IRIX behave
   "properly" -- that is, like other UNIX systems.  When reconfigured, IRIX
   will only give out memory it actually has, and the Merlin and Thor servers
   won't be killed unexpectedly.

   Reconfiguring your kernel is beyond the scope of Daylight's documentation;
   the SGI IRIX System Administration Manual should be consulted.  However,
   below is a brief outline of what must be done:

      1. Edit the file /usr/sysgen/master.d/kernel

      2. At around line 347 is the statement:

            int availsmem_accounting = 0;

         change it to:

            int availsmem_accounting = 1;

      3. Rebuild the kernel (usually done by running autoconfig(1M)).
         Note: if you simply reboot, the kernel will be rebuilt;
               you can then reboot again to use the new kernel.

      4. Reboot.



The Problem:

   If you have a very large database, such as the SPRESI database, your
   kernel may be configured with a memory limit that is too small.

   When you try to load the database into the Merlin server, the server
   will report "Out of memory," even when there is plenty of memory.

The Solution:

   Use the "systune" program to reconfigure your system.  The following
   example illustrates raising the memory limits for each process to 1
   gigabyte (only the super-user can do this):

      # systune -i
      systune-> resource

      group: resource (statically changeable)
             rlimit_rss_max = 536870912 (0x20000000)
             rlimit_rss_cur = 1054482432 (0x3eda2000)
             rlimit_vmem_max = 536870912 (0x20000000)
             rlimit_vmem_cur = 536870912 (0x20000000)
             rlimit_nofile_max = 2500 (0x9c4)
             rlimit_nofile_cur = 200 (0xc8)
             rlimit_core_max = 2147483647 (0x7fffffff)
             rlimit_core_cur = 2147483647 (0x7fffffff)
             rlimit_stack_max = 536870912 (0x20000000)
             rlimit_stack_cur = 67108864 (0x4000000)
             rlimit_data_max = 1073741824 (0x40000000)
             rlimit_data_cur = 1073741824 (0x40000000)
             rlimit_fsize_max = 2147483647 (0x7fffffff)
             rlimit_fsize_cur = 2147483647 (0x7fffffff)
             rlimit_cpu_max = 2147483647 (0x7fffffff)
             rlimit_cpu_cur = 2147483647 (0x7fffffff)

      systune-> rlimit_data_max 0x40000000
                rlimit_data_max =  536870912 (0x20000000)
                Do you really want to change rlimit_data_max to 1073741824
                (0x40000000)? (y/n)  y

   In order for the change in parameter rlimit_data_cur to become
   effective, reboot the system.

   Do the same for:

      systune-> rlimit_data_max 0x40000000      (shown above)
      systune-> rlimit_data_cur 0x40000000
      systune-> rlimit_vmem_cur 0x40000000
      systune-> rlimit_vmem_max 0x40000000
      systune-> rlimit_rss_cur  0x40000000
      systune-> rlimit_rss_max  0x40000000

One customer trying to use more than 1 GB reports that several other
parameters had to be changed:

	rsshogfrac to 98
	gpgshi -- still experimenting?
	gpgslo -- still experimenting?

See the system administration manual for complete details, and consult with
your SGI representative for more assistance.



Occasionally the IRIX operating system will seem to "bog down" -- performance
will be reduced to unacceptable levels.  There appears to be a bug in the IRIX
operating system that causes a process called "vhand" to go out of control and
use 100% of the CPU cycles.

We don't know exactly what triggers this bug, but it seems to occur when a
process causes all swap space to be used.  This can include the Merlin and Thor
servers, which often use lots of memory, but can also be triggered by tar(1),
particularly when reading in tapes with very large files (such as the SPRESI

If your SGI computer is behaving sluggishly, run the top(1) program.  If the
"vhand" program appears to be using nearly 100% of the cpu, try killing all
processes and logging out.  If, after logging back in, the vhand process is
still using nearly 100% of the cpu, then "vhand" has gone bonkers and you have
to reboot.




Beginning with Version 4.41, the nearneighbors program and the daytoolserver
program use System V semaphores for scheduling and process management.  In
some environments, the default numbers of semaphore configured into the
kernel may be too small.  This is indicated by problems starting either of
the above applications.


Reconfigure the kernel with more semaphores.  This is accomplished by performing
the following steps:

1.  Edit the file /usr/sysgen/master.d/sem.  Change the lines which define
the number of semaphores in the system:

#define SEMMNS 256
#define SEMMSL 128

2.  Save the modified file.  Run autoconfig (as user root).

3.  Reboot.

This procedure should increase the number of semaphores sufficiently for 
almost all installations.



Beginning with Version 4.41, the nearneighbors program and the daytoolserver
program use System V semaphores for scheduling and process management.  In
some environments, the default numbers of semaphore configured into the
kernel may be too small.  This is indicated by problems starting either of
the above applications.


Reconfigure the kernel with more semaphores.  This is accomplished by performing
the following steps:

1.  Run 'systune -i' as root.  Within this shell, enter the following two

semmns 256
semmsl 128

2.  Exit the systune shell.

3.  Reboot.

This procedure should increase the number of semaphores sufficiently for 
almost all installations.


APPENDIX: IRIX4 Compatibility With IRIX5

The following is an informal note we received from someone at SGI, describing
the incompatibilities between IRIX 4.x and IRIX 5.x object-code formats.

This information may be out of date.  Contact your SGI Service person,
and/or see your system release notes for the latest information.

                   IRIX4 Compatibility With IRIX5
                          Dave Frederick

Binary Compatibilty between IRIX5 and IRIX4

Almost all IRIX 4.0.X binaries will run on IRIX 5.x.   Because of
some restructuring of IRIX for SVR4 compliance, there are instances
where application code will need to be either recompiled or in some
cases recoded.  Instances where code changes are required include:

   - Programs which read from /dev/kmem will need to use /proc instead.

   - Programs that use /debug, like dbx and cvd (WorkShop), will need to
     use /proc instead.

   - Generally, any products that involve device drivers (e.g. add-on
     boards, some communications products) or other kernel components,
     such as STREAMS modules, must be re-released for IRIX 5.1.

   - Programs not compiled with shared versions of the libraries; for
     example, libfm.a and libgl.a instead of libfm_s.a and libgl_s.a.
     These programs would need to be relinked with the shared versions
     either under IRIX4 or the IRIX4 compatibility mode of IRIX5.

   - For execution on Challenge and Onyx systems, multi-processor programs
     that linked in libmpc.a (-lmpc) explicitly or that have been generated
     using the Power C or Power Fortran analyzers need to be re-linked under
     4.1.1 IDO on 4.0.5x IRIX or re-linked under IRIX4 compatibility mode on
     IRIX5 or fully compiled and linked using the IRIX5 compilers and libraries
     to take advantage of multiple processors on the new R4400 multiprocessor
     systems supported by IRIX5.  Executables of such programs operate
     correctly on IRIX5 Challenge or Onyx MP environments, but they run only
     on a single processor.  This is because new synchronization mechanisms
     are used on the R4400 MP systems.  Those with Power Series systems with
     IRIX5 installed will not need to relink MP binaries with -lmpc on IRIX5;
     4.0.x MP binaries will continue to work in MP fashion on ALL machines
     except Challenge and Onyx.

SVR4 ABI binaries will run without any changes.

Object Compatibilty between IRIX5 and IRIX4

Due to the new binary format used in IRIX 5.x, ELF, object files
created under IRIX 4.0.X (COFF format) cannot be linked with IRIX 5.x
compiled code.  Given the existence of many third party libraries
which will not have been compiled under 5.x, the compilers provide a
compatibility mode such that code compiled under 4.0.x can be linked
with other COFF format objects or libraries on a system running IRIX5.
Each of the compiler products except for Ada have an irix4_ version
of the product, for example the FORTRAN media comes with ftn and
irix4_ftn products.  The current Ada release, 6.2.1, only produces
COFF objects.  See the Known Bugs section of this document for a
list of known problems with compiling in IRIX4 mode on IRIX 5.0.1.

* How to use and not use IRIX4 compatibility mode

In order to use the 'c' compiler in IRIX4 mode, the c *and* irix4_c
products need to be installed (located on the IDO cd).  The /usr/bin/cc
driver invokes the compiler stages with the correct paths when the
environment variable SGI_IRIX4 is set.

Correct usage of IRIX4 compatibility mode:
% setenv SGI_IRIX4 1
% /usr/bin/cc hello.c -v
/usr/irix4/usr/lib/acpp ...
% file a.out
a.out:          MIPSEB COFF executable (paged) not stripped - version 3.12
% unsetenv SGI_IRIX4
% /usr/bin/cc hello.c -v
/usr/lib/cfe ...
% file a.out
a.out:   ELF 32-bit MSB dynamic executable (not stripped) MIPS - version 1

If /usr/irix4/usr/bin/cc is invoked instead of /usr/bin/cc, say if
/usr/irix4/usr/bin is in the PATH before /usr/bin (it is not suggested to put
/usr/irix4/usr/bin in the PATH), then a slightly misleading error message will
be displayed.

Incorrect usage of IRIX4 compatibility mode:
% /usr/irix4/usr/bin/cc hello.c
cc: Error: ANSI C is not installed. (could not find /usr/lib/accom)

The same notions apply to FORTRAN and f77 (requires ftn *and* irix4_ftn;
setenv SGI_IRIX4 1; and use the /usr/bin/f77 driver).

* Installing system header files that are not a part of dev

To use the system header files (eg, /usr/irix4/usr/include/sys/types.h),
the irix4_eoe1.sw.unix subsystem needs to be installed (located on the
IRIX5 CD).  When compiling code in IRIX4 mode that #includes these system
files, the compiler won't be able to find the headers if irix4_eoe1.sw.unix
is not installed and errors will arise.  Trying to mix modes in using the
IRIX5 /usr/include/sys headers (by possibly putting "-I/usr/include" on
the compile line in IRIX4 mode) is the wrong thing to do and will cause
something like this error message:

accom: Error: /usr/include/sgidefs.h, line 113: Incomplete external data
declaration (missing storage class) or function definition missing () before
{function body}
       ERROR -- the macro "_MIPS_SZINT" is unset (currently, must be set to 32)
accom: Error: /usr/include/sgidefs.h, line 113: syntax error
       ERROR -- the macro "_MIPS_SZINT" is unset (currently, must be set to 32)

* What OS release will we stop shipping IRIX4 products?

The IRIX4 products are shipped to help customers during the transition
to IRIX 5.1.  It is yet to be determined in which future release the IRIX4
compatibility mode will be yanked.  5.2?  6.0?

* What are the versions of products, including IRIX4 products, for IRIX5?

     Is in 5.0.1 Release                      Is in 5.1 Release
-------------------------------         -------------------------------
Media Label     Versions output         Media Label     Versions output
-----------     ---------------         -------------   ---------------
On 5.0.1 IDO:                           On 5.1 IDO:
  5.0.1 dev     5.0.1  dev                 5.1   dev    5.1    dev
  irix4_dev     3.10.1 irix4_dev           irix4_dev    3.10.1 irix4_dev
  3.16  c       3.16   c                   3.17  c      3.17   c
  irix4_c       3.10.1 irix4_c             irix4_c      3.10.1 irix4_c
3.1.1 C++       3.1.1 c++               3.2 C++         3.2   c++
  irix4_c++     3.0.1 irix4_c++            irix4_c++    3.0.1 irix4_c++
3.6.1 FORTRAN   3.16  ftn               4.0 FORTRAN     4.0   ftn
  irix4_ftn     3.5.1 irix4_ftn            irix4_ftn    3.5.1 irix4_ftn
1.4.1 Pascal    3.16  pas               1.4.2 Pascal    1.4.2 pas
  irix4_pas     1.3.1 irix4_pas            irix4_pas    1.3.1 irix4_pas
2.3 Power C     2.3   pwrc              2.4 Power C     2.4   pwrc
  irix4_pwrc    2.1.1 irix4_pwrc           irix4_pwrc   2.1.1 irix4_pwrc
3.3 ^ Fortran   3.3   pfa               4.0 ^ Fortran   4.0   pfa
  irix4_pfa     3.1.1 irix4_pfa            irix4_pfa    3.1.1 irix4_pfa

Known Bugs:

* irix4_ftn

Bug #159709:
Using IRIX4 compatibility mode on MR-ed IRIX 5.0.1, the compiler driver
attempts to link in -lftn instead of -lF77 -lU77 -lI77 -lisam.  The result
is that when using "setenv SGI_IRIX4 1; /usr/bin/f77 file.f", FORTRAN code
will not link.  The workaround is to invoke ld manually with the correct
libraries.  This bug applies only to 5.0.1 since the fix is in 5.1.

* irix4_c++

Bug #168556:
Background information-
3.0.1 c++ produces COFF object format.  3.0.1 c++ is compatible with
4.1.1 dev on IRIX 4.0.5.  There is an irix4_c++ product that comes with
3.1.1 c++ for IRIX 5.0.1.  That version of irix4_c++ is the 3.0.1 version.
ELF and COFF objects cannot be mixed.  To use all ELF, ie the 3.1.1 c++,
"/usr/bin/CC file.c".  To use all COFF, ie the 3.0.1 irix4_c++, this is
suppose to work: "setenv SGI_IRIX4 1; /usr/bin/CC file.c".

When using IRIX4 compatibility mode on IRIX 5.0.1, the CC driver tries to
link in an ELF object with the newly compiled COFF objects.  If the IRIX4
compatibility mode is really needed, then workaround the problem by
issuing the setenv SGI_IRIX4 command, compile using -c, and then link by
using the IRIX4 driver:
   setenv SGI_IRIX4 1; CC -c try.c; /usr/irix4/usr/bin/CC try.o

There is no problem with the driver if producing ELF, just recompile
all sources and libraries with /usr/bin/CC (don't setenv SGI_IRIX4).
This is fixed in IRIX 5.1.

* irix4_c

Bug #168471:
When cc is used with the -E option and SGI_IRIX4 env var, then the driver
tries to invoke /usr/irix4/usr/lib/cfe instead of /usr/irix4/usr/lib/acpp.

With IRIX 5.0.1 and the 3.16 c compiler:
% setenv SGI_IRIX4 1
% cc -E -v try.c
/usr/irix4/usr/lib/cfe -D__EXTENSIONS__ -DLANGUAGE_C -D_LANGUAGE_C
-D__INLINE_INTRINSICS -Dsgi -DSVR3 -D__SVR3 -D__sgi -Dunix -Dmips -Dhost_mips
-D__mips=1 -I -D_MIPSEB -DMIPSEB -I/usr/irix4/usr/include try.c -E
-D_LANGUAGE_C-D_CFE -D__unix -D__host_mips -D__DSO__ -std
cc: Error: can't find or exec: /usr/irix4/usr/lib/cfe
  : No such file or directory

A workaround for IRIX 5.0.1 and the 3.16 compiler is to use the
/usr/irix4/usr/bin/cc driver instead of /usr/bin/cc and SGI_IRIX4 when
using the -E option.  In doing so the driver invokes /usr/lib/acpp instead
of /usr/irix4/usr/lib/acpp, but that does not appear to be a problem.
This is fixed in IRIX 5.1.

* irix4_gl_x_dev

Bug #163598:
Installing irix4_gl_x_dev on an IP19 (Challenge, Onyx) or IP22 (Indigo2)
or IP?? (Indy) does not install /usr/irix4/usr/lib/libgl_s.a or libgl.a
for the irix4_gl_x_dev that comes with 5.0.1 IDO.

Typically when this happens it is because the maint cd was not applied as a
final step.  In the case of IRIX 5.0.1 there is no maint cd and no
maint_irix4_gl_x_dev product.

The libgl_s.a and libgl.a libraries are the same for Crimson (IP17) with
RealityEngine graphics as on Onyx or Challenge with RealityEngine graphics,
so the following commands will install the missing files as a workaround.
This bug is fixed in the irix4_gl_x_dev of 5.1 IDO for IRIX 5.1.

% /bin/su
# mkdir /irix4_gl
# inst -r /irix4_gl -m CPUBOARD=IP17 -m GFXBOARD=VENICE -m SUBGR=IP17
-f /CDROM/dist/irix4_gl_x_dev
# cp /irix4_gl/usr/lib/libgl* /usr/irix4/usr/lib
# versions -r /irix4_gl remove irix4_gl_x_dev
# rm -rf /irix4_gl

* irix4_pca

Bug #168939:
When using the -pca option to cc in IRIX4 compatibility mode on IRIX
5.0.1, the cc driver omits the libmpc.a (-lmpc) library on the link line.
This is fixed in IRIX 5.1.

% setenv SGI_IRIX4 1
% cc -pca -v try.c
/usr/irix4/usr/bin/ld -L -L/usr/irix4/usr/lib/ -G 8 -g0 -nocount
/usr/irix4/usr/lib/crt1.o -count try.o -nocount -lc_mp -lkapio -lc
Error: Undefined:

The workaround is to explicity link in -lmpc.  For example:
% setenv SGI_IRIX4 1
% cc -pca try.c -lmpc

* irix4_pfa

Bug #168941:
When using the -pfa option to f77 in IRIX4 compatibility mode on IRIX
5.0.1, the f77 driver passes to the pfa stage illegal options (options
suitable for the IRIX 5.0.1 version of pfa).

% setenv SGI_IRIX4 1
% f77 -pfa -v try.f
/usr/irix4/usr/lib/pfa -L=/usr/tmp/ctmka001BUl1 -F=/usr/tmp/ctmka001BUm1
-I=/usr/tmp/ctmpa001BU -lo=lno -noanalysis -original_filename=try.f
-include=/usr/include -cp=i
 Command line error -- unrecognizable string: "noanalysis"
 PFA -- Command Line Syntax Error Detected

The problem is that the IRIX4 version of pfa does not understand either
of -noanalysis or -original_filename options.  The IRIX4 version of
the -original_filename flag is -customer.  The workaround is to invoke
pfa manually with the correct options.  This is fixed in IRIX 5.1.

* ada 6.2.1 (on 5.0.x == IRIX4 mode)

Bug #159228:
Background info:
AXM 6.2.1 (Ada with X and Motif bindings) installed on 5.0.1 machines
generates COFF objects and therefore tries to link in libraries under

The problem:
The install script, which gets executed as an exit operation to the inst
process, sets the wrong path for the X libraries.  As a result, the ada
pre-linker attempts to find the libraries in /usr/lib (the incompatible
ELF object file format versions) instead of /usr/irix4/usr/lib.

The Workaround:
cd /usr/vads
vi sup/a.install.axi.sgi
   change line 49 to
sup/a.install.sgi .

This is fixed in AXM 6.2.3 and higher.

More IRIX4 tidbits

A few more notes about using the IRIX4 compatibility build environment:

   o If there are undefined symbols, and the linking worked
     on 4.0.x, add -nostdlib -L/usr/irix4/usr/lib or
     -nostdlib -L/usr/irix4/usr/lib -L/usr/irix4/usr/lib/mips2
     to the cc or f77 command line.

   o If the compilation is -mp, add -lI77_mp -lmpc at the end of
     the command line to avoid multiply defined warnings from ld.

   o The -v2 switch is removed in the 3.1 c++ compiler that is
     shipped with IRIX 5.0.  The effect of this is that those
     applications that do not compile under c++ 3.x will not have
     the ability to use 2.x C++ compatibility mode.  The -v2 switch
     option is not available in IRIX4 compatibility mode either
     since it is the 3.x driver that is invoked which no longer
     recognizes -v2.

See Also:

5.0.1 or 5.1 IRIX relnotes if installed ("grelnotes IRIX")