📄 interoperation.html
字号:
<html lang="en"><head><title>Using the GNU Compiler Collection (GCC)</title><meta http-equiv="Content-Type" content="text/html"><meta name="description" content="Using the GNU Compiler Collection (GCC)"><meta name="generator" content="makeinfo 4.6"><!--Copyright © 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,1999, 2000, 2001, 2002, 2003, 2004 Free Software Foundation, Inc. <p>Permission is granted to copy, distribute and/or modify this documentunder the terms of the GNU Free Documentation License, Version 1.2 orany later version published by the Free Software Foundation; with theInvariant Sections being "GNU General Public License" and "FundingFree Software", the Front-Cover texts being (a) (see below), and withthe Back-Cover Texts being (b) (see below). A copy of the license isincluded in the section entitled "GNU Free Documentation License". <p>(a) The FSF's Front-Cover Text is: <p>A GNU Manual <p>(b) The FSF's Back-Cover Text is: <p>You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development.--><meta http-equiv="Content-Style-Type" content="text/css"><style type="text/css"><!-- pre.display { font-family:inherit } pre.format { font-family:inherit } pre.smalldisplay { font-family:inherit; font-size:smaller } pre.smallformat { font-family:inherit; font-size:smaller } pre.smallexample { font-size:smaller } pre.smalllisp { font-size:smaller }--></style></head><body><div class="node"><p>Node: <a name="Interoperation">Interoperation</a>,Next: <a rel="next" accesskey="n" href="External-Bugs.html#External%20Bugs">External Bugs</a>,Previous: <a rel="previous" accesskey="p" href="Cross-Compiler-Problems.html#Cross-Compiler%20Problems">Cross-Compiler Problems</a>,Up: <a rel="up" accesskey="u" href="Trouble.html#Trouble">Trouble</a><hr><br></div><h3 class="section">Interoperation</h3><p>This section lists various difficulties encountered in using GCCtogether with other compilers or with the assemblers, linkers,libraries and debuggers on certain systems. <ul><li>On many platforms, GCC supports a different ABI for C++ than do othercompilers, so the object files compiled by GCC cannot be used with objectfiles generated by another C++ compiler. <p>An area where the difference is most apparent is name mangling. The useof different name mangling is intentional, to protect you from more subtleproblems. Compilers differ as to many internal details of C++ implementation,including: how class instances are laid out, how multiple inheritance isimplemented, and how virtual function calls are handled. If the nameencoding were made the same, your programs would link against librariesprovided from other compilers--but the programs would then crash whenrun. Incompatible libraries are then detected at link time, rather thanat run time. </p><li>Older GDB versions sometimes fail to read the output of GCC version2. If you have trouble, get GDB version 4.4 or later. <li>DBX rejects some files produced by GCC, though it accepts similarconstructs in output from PCC. Until someone can supply a coherentdescription of what is valid DBX input and what is not, there isnothing I can do about these problems. You are on your own. <li>The GNU assembler (GAS) does not support PIC. To generate PIC code, youmust use some other assembler, such as <code>/bin/as</code>. <li>On some BSD systems, including some versions of Ultrix, use of profilingcauses static variable destructors (currently used only in C++) not tobe run. <li>On some SGI systems, when you use <code>-lgl_s</code> as an option,it gets translated magically to <code>-lgl_s -lX11_s -lc_s</code>. Naturally, this does not happen when you use GCC. You must specify all three options explicitly. <li>On a SPARC, GCC aligns all values of type <code>double</code> on an 8-byteboundary, and it expects every <code>double</code> to be so aligned. The Suncompiler usually gives <code>double</code> values 8-byte alignment, with oneexception: function arguments of type <code>double</code> may not be aligned. <p>As a result, if a function compiled with Sun CC takes the address of anargument of type <code>double</code> and passes this pointer of type<code>double *</code> to a function compiled with GCC, dereferencing thepointer may cause a fatal signal. <p>One way to solve this problem is to compile your entire program with GCC. Another solution is to modify the function that is compiled withSun CC to copy the argument into a local variable; local variablesare always properly aligned. A third solution is to modify the functionthat uses the pointer to dereference it via the following function<code>access_double</code> instead of directly with <code>*</code>: <pre class="smallexample"> 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; } </pre> <p>Storing into the pointer can be done likewise with the same union. </p><li>On Solaris, the <code>malloc</code> function in the <code>libmalloc.a</code> librarymay allocate memory that is only 4 byte aligned. Since GCC on theSPARC assumes that doubles are 8 byte aligned, this may result in afatal signal if doubles are stored in memory allocated by the<code>libmalloc.a</code> library. <p>The solution is to not use the <code>libmalloc.a</code> library. Use instead<code>malloc</code> and related functions from <code>libc.a</code>; they do not havethis problem. </p><li>Sun forgot to include a static version of <code>libdl.a</code> with someversions of SunOS (mainly 4.1). This results in undefined symbols whenlinking static binaries (that is, if you use <code>-static</code>). If yousee undefined symbols <code>_dlclose</code>, <code>_dlsym</code> or <code>_dlopen</code>when linking, compile and link against the file<code>mit/util/misc/dlsym.c</code> from the MIT version of X windows. <li>The 128-bit long double format that the SPARC port supports currentlyworks by using the architecturally defined quad-word floating pointinstructions. Since there is no hardware that supports theseinstructions they must be emulated by the operating system. Longdoubles do not work in Sun OS versions 4.0.3 and earlier, because thekernel emulator uses an obsolete and incompatible format. Long doublesdo 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 GCCdoes not enable them by default. Long doubles appear to work in Sun OS5.x (Solaris 2.x). <li>On HP-UX version 9.01 on the HP PA, the HP compiler <code>cc</code> does notcompile GCC correctly. We do not yet know why. However, GCCcompiled on earlier HP-UX versions works properly on HP-UX 9.01 and cancompile itself properly on 9.01. <li>On the HP PA machine, ADB sometimes fails to work on functions compiledwith GCC. Specifically, it fails to work on functions that use<code>alloca</code> or variable-size arrays. This is because GCC doesn'tgenerate HP-UX unwind descriptors for such functions. It may even beimpossible to generate them. <li>Debugging (<code>-g</code>) is not supported on the HP PA machine, unless you usethe preliminary GNU tools. <li>Taking the address of a label may generate errors from the HP-UXPA assembler. GAS for the PA does not have this problem. <li>Using floating point parameters for indirect calls to static functionswill not work when using the HP assembler. There simply is no way for GCCto specify what registers hold arguments for static functions when usingthe HP assembler. GAS for the PA does not have this problem. <li>In extremely rare cases involving some very large functions you mayreceive errors from the HP linker complaining about an out of boundsunconditional branch offset. This used to occur more often in previousversions of GCC, but is now exceptionally rare. If you should runinto it, you can work around by making your function smaller. <li>GCC compiled code sometimes emits warnings from the HP-UX assembler ofthe form: <pre class="smallexample"> (warning) Use of GR3 when frame >= 8192 may cause conflict. </pre> <p>These warnings are harmless and can be safely ignored. </p><li>On the IBM RS/6000, compiling code of the form <pre class="smallexample"> extern int foo; ... foo ... static int foo; </pre> <p>will cause the linker to report an undefined symbol <code>foo</code>. Although this behavior differs from most other systems, it is not abug because redefining an <code>extern</code> variable as <code>static</code>is undefined in ISO C. </p><li>In extremely rare cases involving some very large functions you mayreceive errors from the AIX Assembler complaining about a displacementthat is too large. If you should run into it, you can work around bymaking your function smaller. <li>The <code>libstdc++.a</code> library in GCC relies on the SVR4 dynamiclinker semantics which merges global symbols between libraries andapplications, especially necessary for C++ streams functionality. This is not the default behavior of AIX shared libraries and dynamiclinking. <code>libstdc++.a</code> is built on AIX with "runtime-linking"enabled so that symbol merging can occur. To utilize this feature,the application linked with <code>libstdc++.a</code> must include the<code>-Wl,-brtl</code> flag on the link line. G++ cannot impose thisbecause this option may interfere with the semantics of the userprogram and users may not always use <code>g++</code> to link his or herapplication. Applications are not required to use the<code>-Wl,-brtl</code> flag on the link line--the rest of the<code>libstdc++.a</code> library which is not dependent on the symbolmerging semantics will continue to function correctly. <li>An application can interpose its own definition of functions forfunctions invoked by <code>libstdc++.a</code> with "runtime-linking"enabled on AIX. To accomplish this the application must be linkedwith "runtime-linking" option and the functions explicitly must beexported by the application (<code>-Wl,-brtl,-bE:exportfile</code>). <li>AIX on the RS/6000 provides support (NLS) for environments outside ofthe United States. Compilers and assemblers use NLS to supportlocale-specific representations of various objects includingfloating-point numbers (<code>.</code> vs <code>,</code> for separating decimalfractions). There have been problems reported where the library linkedwith GCC does not produce the same floating-point formats that theassembler accepts. If you have this problem, set the <code>LANG</code>environment variable to <code>C</code> or <code>En_US</code>. <li>Even if you specify <code>-fdollars-in-identifiers</code>,you cannot successfully use <code>$</code> in identifiers on the RS/6000 dueto a restriction in the IBM assembler. GAS supports theseidentifiers. <li>On Ultrix, the Fortran compiler expects registers 2 through 5 to be savedby function calls. However, the C compiler uses conventions compatiblewith BSD Unix: registers 2 through 5 may be clobbered by function calls. <p>GCC uses the same convention as the Ultrix C compiler. You can usethese options to produce code compatible with the Fortran compiler: <pre class="smallexample"> -fcall-saved-r2 -fcall-saved-r3 -fcall-saved-r4 -fcall-saved-r5 </pre> </p><li>On the Alpha, you may get assembler errors about invalid syntax as aresult of floating point constants. This is due to a bug in the Clibrary functions <code>ecvt</code>, <code>fcvt</code> and <code>gcvt</code>. Given validfloating point numbers, they sometimes print <code>NaN</code>. </ul> </body></html>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -