SGI Freeware: gcc 3.3

gcc-3.3: description + notes

This is gcc, a version of the GNU C compiler. In addition to C, this package includes C++ (g++), Objective-C (objc), FORTRAN (g77), and java (gcj) language front-ends, plus the protoize, unprotoize, and gcov utilities. The GCC Home Page has on-line information and documentation. Because of its large size and instability java support is not installed by default, but it is included in a separate fw_gcc.sw.java subsys if you want to install it explicitly.
gcc version 2.8 and upwards support SGI's new ABIs (n32 and 64). The default compilation mode is n32 (-mabi=n32). To compile 64-bit use: gcc -mabi=64 ...
gcc version 3.0 introduced a new C++ ABI. C++ libraries compiled with pre-3.0 versions are not interoperable with programs built with version 3.0 or later, and vice versa. See the GCC FAQ for more information. A copy of pre-3.0 gcc is available from http://freeware.sgi.com/fw-6.2/index-by-alpha.html#gcc.

This gcc requires the SGI back-end (assembler and linker) since the GNU back-end (binutils) doesn't yet support the new SGI ABIs.
The SGI back end (including an assembler and linker supporting the n32 and 64 ABIs) plus all the bits and pieces needed for gcc (headers, libraries, runtime startup files, etc.) are included for free with any IRIX 6.5 distribution on the 2 CDs titled Development Foundation and Development Libraries (in other words you don't need to have the SGI IDO in order to use gcc.) In recent SGI compiler releases, the SGI assembler and linker are in the subsystem compiler_dev.sw.base. For older IRIX 6.x releases you can download the IRIX Development Foundation and Libraries from SGI Developer Archive.

Troubleshooting (symptom/resolution items)
ld32: FATAL 9: I/O error (/usr/lib32/mips3/crt1.o): No such file or directory.
You haven't installed all the necessary pieces from the Development Libraries CD. Specifically: /usr/lib32/mips3/crt1.o is in the dev.sw.lib subsystem on that CD or equivalent.

file.c:1: stdio.h: No such file or directory
You haven't installed the IRIX standard headers. You may find them in IRIX inside irix_dev.sw.headers or in the compiler/development CD in compiler_dev.hdr.lib.

/usr/include/string.h:67: warning: conflicting types for built-in function `memcpy' (or memcmp/memset/strlen)
When you compile with the -mips3 option you should suppress the gcc builtins i.e.:
gcc -fno-builtin -mips3 ...

Assembler messages:

Fatal error: No compiled in support for 64 bit object file format
You're running gcc 2.8.1 in 64-bit mode (gcc -mabi=64) but using the GNU assembler which doesn't support the 64-bit abi. Make sure that as in your PATH is the SGI assembler rather than the GNU assembler. You may rename the GNU assembler to gas to prevent this.

as: unrecognized option `-n32'
Again, you're running the GNU assembler rather than the SGI assembler.
The most probable reason is that you have an older version of the GNU compiler (gcc 2.7.x) and binutils installed in your PATH (/usr/freeware/bin/as or /usr/gnu/bin/as). To verify this run gcc with the -v option and see which assembler (as) is being called.
Two possible fixes:

Rename the gnu assembler under /usr/freeware/bin or /usr/gnu/bin to gas (best if you still want to keep gcc 2.7.x and the o32 ABI GNU capability)
Remove the old GNU as altogether.

ld: FATAL 43: cannot mix PIC and non-PIC: ...
You are trying to mix PIC and non-PIC code, most probably by an incorrect use of -Bstatic. Note that on new IRIX systems, archives (.a files) are not statically linked objects but archives of dynamically linked objects. People tend to say "I want static linking" when they actually mean: "I want to use a .a library instead of a .so library."
Anyway: the correct way of mixing statically linked code with dynamically linked code is to alternate the mode of linking between libraries. Here's an example of the correct way to link with the GTK+ libraries:
   gcc -o foo foo.o 
        -L/path/to/gtk/lib -Wl,-B,static -lgtk -lgdk -lglib 
        -Wl,-B,dynamic -lXext -lX11 -lm
Note the switching between dynamic linking (default) to static linking with some freeware libraries (-lgtk -lgdk -lglib) and back to dynamic linking with the SGI X11 and libm libraries.
(Many thanks to Erik Mouw for this one)
ld: FATAL 9: I/O error (-lc): No such file or directory
ld: FATAL 9: I/O error (-lm): No such file or directory
Basically: the linker cannot find your standard C (or math) library. The reasons may vary. You may be on a IRIX 6.2 system but you haven't installed the n32 libraries (eoe.sw32.lib for the IRIX CD.) This is the most common cause. Or you may be compiling with -mabi=64 but you don't have the 64-bit libraries installed on your system. You may otherwise have some bad seetings for environment variables that affect the search for DSOs such as LD_LIBRARY_PATH, _RLD_ROOT, etc. See man dso. Try to run gcc with the -v option to see which linker is being called (e.g. does it get invoked with -n32 ?). This may help figuring out the problem

Various strange errors running purify on gcc-compiled code
Try installing patch 3944 or its successor.
Known Bugs

Unlike MIPSpro cc, gcc does not support the o32 (old 32 bit) ABI.
Unlike MIPSpro cc, gcc does not support 128-bit long double or (in FORTRAN) real*16 quantities.
From Jim Wilson and Andy Polyakov: Gcc does not correctly pass/return structures that are smaller than 16 bytes and which are not 8 bytes. The problem is very involved and difficult to fix. It affects a number of other targets also, but irix6 is affected the most, because it is a 64 bit target, and 4 byte structures are common. The exact problem is that structures are being padded at the wrong end, e.g. a 4 byte structure is loaded into the lower 4 bytes of the register when it should be loaded into the upper 4 bytes of the register.
Gcc is consistent with itself, but not consistent with the SGI C compiler and the SGI supplied runtime libraries, so the only failures that can happen are when there are library functions that take/return such structures. There are very few such library functions, but inet_ntoa, inet_lnaof, inet_netof, inet_makeaddr and semctl are all examples. Work-arounds for these particular routines have been built into libgcc.a, but that is not a general fix. If you find more instances in IRIX libraries please report them. Often a small wrapper procedure that realigns the problematic arguments will avoid the problem.

If you wish to report a problem, always make sure to include enough details (exact invocation line, full error message) so we can figure it out.
Hearty thanks to Erik Mouw, Martin Knoblauch, and Andy Polyakov.
To auto-install this package, go back and click on the respective install icon.