]>
Commit | Line | Data |
---|---|---|
1 | .. | |
2 | Copyright 1988-2022 Free Software Foundation, Inc. | |
3 | This is part of the GCC manual. | |
4 | For copying conditions, see the copyright.rst file. | |
5 | ||
6 | .. _interoperation: | |
7 | ||
8 | Interoperation | |
9 | ************** | |
10 | ||
11 | This section lists various difficulties encountered in using GCC | |
12 | together with other compilers or with the assemblers, linkers, | |
13 | libraries and debuggers on certain systems. | |
14 | ||
15 | * On many platforms, GCC supports a different ABI for C++ than do other | |
16 | compilers, so the object files compiled by GCC cannot be used with object | |
17 | files generated by another C++ compiler. | |
18 | ||
19 | An area where the difference is most apparent is name mangling. The use | |
20 | of different name mangling is intentional, to protect you from more subtle | |
21 | problems. | |
22 | Compilers differ as to many internal details of C++ implementation, | |
23 | including: how class instances are laid out, how multiple inheritance is | |
24 | implemented, and how virtual function calls are handled. If the name | |
25 | encoding were made the same, your programs would link against libraries | |
26 | provided from other compilers---but the programs would then crash when | |
27 | run. Incompatible libraries are then detected at link time, rather than | |
28 | at run time. | |
29 | ||
30 | * On some BSD systems, including some versions of Ultrix, use of profiling | |
31 | causes static variable destructors (currently used only in C++) not to | |
32 | be run. | |
33 | ||
34 | * On a SPARC, GCC aligns all values of type ``double`` on an 8-byte | |
35 | boundary, and it expects every ``double`` to be so aligned. The Sun | |
36 | compiler usually gives ``double`` values 8-byte alignment, with one | |
37 | exception: function arguments of type ``double`` may not be aligned. | |
38 | ||
39 | As a result, if a function compiled with Sun CC takes the address of an | |
40 | argument of type ``double`` and passes this pointer of type | |
41 | ``double *`` to a function compiled with GCC, dereferencing the | |
42 | pointer may cause a fatal signal. | |
43 | ||
44 | One way to solve this problem is to compile your entire program with GCC. | |
45 | Another solution is to modify the function that is compiled with | |
46 | Sun CC to copy the argument into a local variable; local variables | |
47 | are always properly aligned. A third solution is to modify the function | |
48 | that uses the pointer to dereference it via the following function | |
49 | ``access_double`` instead of directly with :samp:`*`: | |
50 | ||
51 | .. code-block:: c++ | |
52 | ||
53 | inline double | |
54 | access_double (double *unaligned_ptr) | |
55 | { | |
56 | union d2i { double d; int i[2]; }; | |
57 | ||
58 | union d2i *p = (union d2i *) unaligned_ptr; | |
59 | union d2i u; | |
60 | ||
61 | u.i[0] = p->i[0]; | |
62 | u.i[1] = p->i[1]; | |
63 | ||
64 | return u.d; | |
65 | } | |
66 | ||
67 | Storing into the pointer can be done likewise with the same union. | |
68 | ||
69 | * On Solaris, the ``malloc`` function in the :samp:`libmalloc.a` library | |
70 | may allocate memory that is only 4 byte aligned. Since GCC on the | |
71 | SPARC assumes that doubles are 8 byte aligned, this may result in a | |
72 | fatal signal if doubles are stored in memory allocated by the | |
73 | :samp:`libmalloc.a` library. | |
74 | ||
75 | The solution is to not use the :samp:`libmalloc.a` library. Use instead | |
76 | ``malloc`` and related functions from :samp:`libc.a`; they do not have | |
77 | this problem. | |
78 | ||
79 | * On the HP PA machine, ADB sometimes fails to work on functions compiled | |
80 | with GCC. Specifically, it fails to work on functions that use | |
81 | ``alloca`` or variable-size arrays. This is because GCC doesn't | |
82 | generate HP-UX unwind descriptors for such functions. It may even be | |
83 | impossible to generate them. | |
84 | ||
85 | * Debugging (:option:`-g`) is not supported on the HP PA machine, unless you use | |
86 | the preliminary GNU tools. | |
87 | ||
88 | * Taking the address of a label may generate errors from the HP-UX | |
89 | PA assembler. GAS for the PA does not have this problem. | |
90 | ||
91 | * Using floating point parameters for indirect calls to static functions | |
92 | will not work when using the HP assembler. There simply is no way for GCC | |
93 | to specify what registers hold arguments for static functions when using | |
94 | the HP assembler. GAS for the PA does not have this problem. | |
95 | ||
96 | * In extremely rare cases involving some very large functions you may | |
97 | receive errors from the HP linker complaining about an out of bounds | |
98 | unconditional branch offset. This used to occur more often in previous | |
99 | versions of GCC, but is now exceptionally rare. If you should run | |
100 | into it, you can work around by making your function smaller. | |
101 | ||
102 | * GCC compiled code sometimes emits warnings from the HP-UX assembler of | |
103 | the form: | |
104 | ||
105 | .. code-block:: c++ | |
106 | ||
107 | (warning) Use of GR3 when | |
108 | frame >= 8192 may cause conflict. | |
109 | ||
110 | These warnings are harmless and can be safely ignored. | |
111 | ||
112 | * In extremely rare cases involving some very large functions you may | |
113 | receive errors from the AIX Assembler complaining about a displacement | |
114 | that is too large. If you should run into it, you can work around by | |
115 | making your function smaller. | |
116 | ||
117 | * The :samp:`libstdc++.a` library in GCC relies on the SVR4 dynamic | |
118 | linker semantics which merges global symbols between libraries and | |
119 | applications, especially necessary for C++ streams functionality. | |
120 | This is not the default behavior of AIX shared libraries and dynamic | |
121 | linking. :samp:`libstdc++.a` is built on AIX with 'runtime-linking' | |
122 | enabled so that symbol merging can occur. To utilize this feature, | |
123 | the application linked with :samp:`libstdc++.a` must include the | |
124 | :option:`-Wl,-brtl` flag on the link line. G++ cannot impose this | |
125 | because this option may interfere with the semantics of the user | |
126 | program and users may not always use :samp:`g++` to link his or her | |
127 | application. Applications are not required to use the | |
128 | :option:`-Wl,-brtl` flag on the link line---the rest of the | |
129 | :samp:`libstdc++.a` library which is not dependent on the symbol | |
130 | merging semantics will continue to function correctly. | |
131 | ||
132 | * An application can interpose its own definition of functions for | |
133 | functions invoked by :samp:`libstdc++.a` with 'runtime-linking' | |
134 | enabled on AIX. To accomplish this the application must be linked | |
135 | with 'runtime-linking' option and the functions explicitly must be | |
136 | exported by the application (:option:`-Wl,-brtl,-bE:exportfile`). | |
137 | ||
138 | * AIX on the RS/6000 provides support (NLS) for environments outside of | |
139 | the United States. Compilers and assemblers use NLS to support | |
140 | locale-specific representations of various objects including | |
141 | floating-point numbers (:samp:`.` vs :samp:`,` for separating decimal | |
142 | fractions). There have been problems reported where the library linked | |
143 | with GCC does not produce the same floating-point formats that the | |
144 | assembler accepts. If you have this problem, set the :envvar:`LANG` | |
145 | environment variable to :samp:`C` or :samp:`En_US`. | |
146 | ||
147 | * | |
148 | .. index:: fdollars-in-identifiers | |
149 | ||
150 | Even if you specify :option:`-fdollars-in-identifiers`, | |
151 | you cannot successfully use :samp:`$` in identifiers on the RS/6000 due | |
152 | to a restriction in the IBM assembler. GAS supports these | |
153 | identifiers. |