Contents|Index|Previous|Next
Interoperation
The following documentation
lists various difficulties encountered in using GNU C or GNU C++ together
with other compilers or with the assemblers, linkers, libraries and debuggers
on certain systems.
-
Objective C does not work on
the RS/6000.
-
GNU C++ does not do name mangling
in the same way as other C++ compilers. This means that object files compiled
with one compiler cannot be used with another compiler.
-
This effect is intentional,
to protect you from more subtle problems. Compilers differ as to many internal
details of C++ implementation, including: how class instances are laid
out, how multiple inheritance is implemented, and how virtual function
calls are handled.
-
If the name encoding were made
the same, your programs would link against libraries provided from other
compilersbut the programs would then crash when run. Incompatible libraries
are then detected at link time, rather than at run time.
-
Older GDB versions sometimes
fail to read the output of GNU CC version 2. If you have trouble, get GDB
version 4.4 or later.
-
DBX rejects some files produced
by GNU CC, though it accepts similar constructs in output from PCC. Until
someone can supply a coherent description of what is valid DBX input and
what is not, there is nothing we can do about these problems. You are on
your own.
-
The GNU assembler (GAS) does
not support PIC. To generate PIC code, you must use some other assembler,
such as /bin/as.
-
On some BSD systems, including
some versions of Ultrix, use of profiling causes static variable destructors
(currently used only in C++) not to be run.
-
Use of -I/usr/include
may cause trouble.
-
Many systems come with header
files that wont work with GNU CC unless corrected by fixincludes.
The corrected header files go in a new directory; GNU CC searches this
directory before /usr/include.
If you use -I/usr/include,
this tells GNU CC to search /usr/include
earlier on, before the corrected headers. The result is that you get the
uncorrected header files.
-
Instead, you should use these
options (when compiling C programs):
-I/usr/local/lib/gcc-lib/target/version/include \ -I/usr/include
For C++ programs, GNU CC also
uses a special directory that defines C++ interfaces to standard C subroutines.
This directory is meant to be searched before other standard include
directories, so that it takes precedence. If you are compiling C++ programs
and specifying include directories explicitly, use this option first, then
the two previous options:
-I/usr/local/lib/g++-include
On some SGI systems, when you
use -lgl_s
as an option, it gets translated magically to -lgl_s
-lX11_s -lc_s.
Naturally, this does not happen when you use GNU CC. You must specify all
three options explicitly.
On a SPARC, GNU CC aligns all
values of type double on an 8-byte boundary, and it expects every double
to be so aligned. The Sun compiler usually gives double
values 8-byte alignment, with one exception: function arguments of type
double
may not be aligned.
As a result, if a function compiled
with Sun CC takes the address of an argument of type double
and passes this pointer of type double*
to a function compiled with GNU CC, de-referencing the pointer may cause
a fatal signal.
One way to solve this problem
is to compile your entire program with GNU CC. Another solution is to modify
the function that is compiled with Sun CC to copy the argument into a local
variable; local variables are always properly aligned.
A third solution is to modify
the function that uses the pointer to de-reference it using the following
function, access_double,
instead of directly with *:
inline double
access_double (double *unaligned_ptr)
{
union d2i { double d; int i[2]; };
union d2i *p = (union d2i *) unaligned_ptr;
union d2i u;
u.i[0] = p->i[0];
u.i[1] = p->i[1];
return u.d;
}
Storing into the pointer can
be done likewise with the same union.
On Solaris, the malloc
function in the libmalloc.a
library may allocate memory that is only 4 byte aligned. Since GNU CC on
the Sparc assumes that doubles are 8 byte aligned, this may result in a
fatal signal if doubles are stored in memory allocated by the libmalloc.a
library.
The solution is to not use the
libmalloc.a
library. Instead, use malloc
and related functions from libc.a;
they do not have this problem.
Sun forgot to include a static
version of libdl.a
with some versions of SunOS (mainly 4.1). This results in undefined symbols
when linking static binaries (that is, if you use -static).
If you see undefined symbols _dlclose,
_dlsym
or _dlopen
when linking, compile and link against the file, mit/util/misc/dlsym.c,
from the MIT version of X windows.
The 128-bit long
double
format that the Sparc port supports currently works by using the architecturally
defined quad-word floating point instructions. Since there is no hardware
that supports these instructions they must be emulated by the operating
system.
Long doubles do not work in
Sun OS versions 4.0.3 and earlier, because the kernel emulator uses an
obsolete and incompatible format. Long doubles do not work in Sun OS version
4.1.1 due to a problem in a Sun library. Long doubles do work on Sun OS
versions 4.1.2 and higher, but GNU CC does not enable them by default.
Long doubles appear to work in Sun OS 5.x (Solaris 2.x).
On HPUX version 9.01 on the
HPPA, the HP compiler, cc,
does not compile GNU CC correctly. We do not yet know why. However, GNU
CC compiled on earlier HPUX versions works properly on HPUX 9.01 and can
compile itself properly on 9.01.
On the HPPA machine, ADB sometimes
fails to work on functions compiled with GNU CC. Specifically, it fails
to work on functions that use alloca
or variable-size arrays. This is because GNU CC doesnt generate HPUX unwind
descriptors for such functions. It may even be impossible to generate them.
Debugging -g
is not supported on the HP PA machine, unless you use the preliminary GNU
tools (see Installing GNU CC).
Taking the address of a label
may generate errors from the HPUX PA assembler. GAS for the PA does not
have this problem.
Using floating point parameters
for indirect calls to static functions will not work when using the HP
assembler. There simply is no way for GCC to specify what registers hold
arguments for static functions when using the HP assembler. GAS for the
PA does not have this problem.
In extremely rare cases involving
some very large functions you may receive errors from the HP linker complaining
about an out of bounds unconditional branch offset. This used to occur
more often in previous versions of GNU CC, but is now exceptionally rare.
If you should run into it, you can work around by making your function
smaller.
GNU CC compiled code sometimes
emits warnings from the HPUX assembler of the following form.
(warning) Use of GR3 when
frame >= 8192 may cause conflict.
These warnings are harmless
and can be safely ignored.
The current version of the assembler
(/bin/as)
for the RS/6000 has certain problems that prevent the -g
option in GCC from working. Note that Makefile.in
uses -g
by default when compiling libgcc2.c.
IBM has produced a fixed version
of the assembler. The upgraded assembler unfortunately was not included
in any of the AIX 3.2 update PTF releases (3.2.2, 3.2.3, or 3.2.3e). Users
of AIX 3.1 should request PTF U403044 from IBM and users of AIX 3.2 should
request PTF U416277. See the file README.RS6000
for more details on these updates.
You can test for the presence
of a fixed assembler by using the command
as -u < /dev/null
If the command exits normally,
the assembler fix already is installed. If the assembler complains that
-u
is an unknown flag, you need to order the fix.
On the IBM RS/6000, compiling
code of the following form will cause the linker to report an undefined
symbol, foo.
extern int foo;
... foo ...
static int foo;
Although this behavior differs
from most other systems, it is not a bug because redefining an extern
variable as static
is undefined in ANSI C.
AIX on the RS/6000 provides
support (NLS) for environments outside of the United States. Compilers
and assemblers use NLS to support locale-specific representations of various
objects including floating-point numbers (.
vs ,
for separating decimal fractions). There have been problems reported where
the library linked with GCC does not produce the same floating-point formats
that the assembler accepts. If you have this problem, set the LANG
environment variable to C
or En US.
-
Even if you specify -fdollars-in-identifiers,
you cannot successfully use $
in identifiers on the RS/6000 due to a restriction in the IBM assembler.
GAS supports these identifiers.
-
On the RS/6000, XLC version
1.3.0.0 will miscompile jump.c.
XLC version 1.3.0.1 or later fixes this problem. You can obtain XLC-1.3.0.2
by requesting PTF 421749 from IBM.
-
There is an assembler bug in
versions of DG/UX prior to 5.4.2.01 that occurs when the fldcr
instruction is used. GNU CC uses fldcr
on the 88100 to serialize volatile memory references. Use the option, -mno-serialize-volatile,
if your version of the assembler has this bug.
-
On VMS, GAS versions 1.38.1
and earlier may cause spurious warning messages from the linker. These
warning messages complain of mismatched psect
attributes. You can ignore them. See Installing GNU CC on VMS on page
154.
-
On NewsOS version 3, if you
include both of the files stddef.h
and sys/types.h,
you get an error because there are two typedefs of size_t.
You should change sys/types.h
by adding the following lines around the definition of size_t.
#ifndef _SIZE_T
#define _SIZE_T
actual typedef here
#endif
On the Alliant, the systems
own convention for returning structures and unions is unusual, and is not
compatible with GNU CC no matter what options are used.
On the IBM RT PC, the MetaWare
HighC compiler (hc) uses a different convention for structure and union
returning.
Use the option, -mhc-struct-return,
to tell GNU CC to use a convention compatible with it.
On Ultrix, the Fortran compiler
expects registers 2 through 5 to be saved by function calls. However, the
C compiler uses conventions compatible with BSD Unix: registers 2 through
5 may be clobbered by function calls. GNU CC uses the same convention as
the Ultrix C compiler. Use the following options to produce code compatible
with the Fortran compiler.
-fcall-saved-r2 -fcall-saved-r3
-fcall-saved-r4 -fcall-saved-r5
On the WE32k, you may find that
programs compiled with GNU CC do not work with the standard shared C library.
You may need to link with the ordinary C compiler. If you do so, you must
specify the following options:
-L/usr/local/lib/gcc-lib/we32k-att-sysv/2.8.1 -lgcc -lc_s
The first specifies where to
find the library, libgcc.a,
specified with the -lgcc
option.
GNU CC does linking by invoking
ld,
just as cc
does, and there is no reason why it should matter which compilation program
you use to invoke ld.
If someone tracks this problem down, it can probably be fixed easily.
On the Alpha, you may get assembler
errors about invalid syntax as a result of floating point constants. This
is due to a bug in the C library functions ecvt,
fcvt
and gcvt.
Given valid floating point numbers, they sometimes print NaN.
On Irix 4.0.5F (and perhaps
in some other versions), an assembler bug sometimes reorders instructions
incorrectly when optimization is turned on. If you think this may be happening
to you, try using the GNU assembler; GAS version 2.1 supports ECOFF on
Irix.
Or use the -noasmopt
option when you compile GNU CC with itself, and then again when you compile
your program. (This is a temporary kludge to turn off assembler optimization
on Irix.) If this proves to be what you need, edit the assembler spec in
the file, specs
so that it unconditionally passes -O0
to the assembler, and never passes -O2
or -O3.
Top|Contents|Index|Previous|Next