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 Central.
|
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.
|