]>
Commit | Line | Data |
---|---|---|
8a165db0 BK |
1 | <sect1 id="appendix.porting.abi" xreflabel="abi"> |
2 | <?dbhtml filename="abi.html"?> | |
3 | ||
4 | <sect1info> | |
5 | <keywordset> | |
6 | <keyword> | |
7 | C++ | |
8 | </keyword> | |
9 | <keyword> | |
10 | ABI | |
11 | </keyword> | |
12 | <keyword> | |
13 | version | |
14 | </keyword> | |
15 | <keyword> | |
16 | dynamic | |
17 | </keyword> | |
18 | <keyword> | |
19 | shared | |
20 | </keyword> | |
21 | </keywordset> | |
22 | </sect1info> | |
23 | ||
24 | <title>ABI Policy and Guidelines</title> | |
25 | ||
26 | <para> | |
27 | </para> | |
28 | ||
29 | <sect2 id="abi.cxx_interface" xreflabel="abi.cxx_interface"> | |
30 | <title>The C++ Interface</title> | |
31 | ||
32 | <para> | |
33 | C++ applications often dependent on specific language support | |
34 | routines, say for throwing exceptions, or catching exceptions, and | |
35 | perhaps also dependent on features in the C++ Standard Library. | |
36 | </para> | |
37 | ||
38 | <para> | |
39 | The C++ Standard Library has many include files, types defined in | |
40 | those include files, specific named functions, and other | |
41 | behavior. The text of these behaviors, as written in source include | |
42 | files, is called the Application Programing Interface, or API. | |
43 | </para> | |
44 | ||
45 | <para> | |
46 | Furthermore, C++ source that is compiled into object files is | |
47 | transformed by the compiler: it arranges objects with specific | |
48 | alignment and in a particular layout, mangling names according to a | |
49 | well-defined algorithm, has specific arrangements for the support of | |
50 | virtual functions, etc. These details are defined as the compiler | |
51 | Application Binary Interface, or ABI. The GNU C++ compiler uses an | |
52 | industry-standard C++ ABI starting with version 3. Details can be | |
53 | found in the <ulink | |
54 | url="http://www.codesourcery.com/cxx-abi/abi.html"> ABI | |
55 | specification</ulink>. | |
56 | </para> | |
57 | ||
58 | <para> | |
59 | The GNU C++ compiler, g++, has a compiler command line option to | |
60 | switch between various different C++ ABIs. This explicit version | |
61 | switch is the flag <code>-fabi-version</code>. In addition, some | |
62 | g++ command line options may change the ABI as a side-effect of | |
63 | use. Such flags include <code>-fpack-struct</code> and | |
64 | <code>-fno-exceptions</code>, but include others: see the complete | |
65 | list in the GCC manual under the heading <ulink url="http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#Code%20Gen%20Options">Options | |
66 | for Code Generation Conventions</ulink>. | |
67 | </para> | |
68 | ||
69 | <para> | |
70 | The configure options used when building a specific libstdc++ | |
71 | version may also impact the resulting library ABI. The available | |
72 | configure options, and their impact on the library ABI, are | |
73 | documented | |
74 | <ulink url="http://gcc.gnu.org/onlinedocs/libstdc++/configopts.html"> | |
75 | here</ulink>. | |
76 | </para> | |
77 | ||
78 | <para> Putting all of these ideas together results in the C++ Standard | |
79 | library ABI, which is the compilation of a given library API by a | |
80 | given compiler ABI. In a nutshell: | |
81 | </para> | |
82 | ||
83 | <para> | |
84 | <quote> | |
85 | library API + compiler ABI = library ABI | |
86 | </quote> | |
87 | </para> | |
88 | ||
89 | <para> | |
90 | The library ABI is mostly of interest for end-users who have | |
91 | unresolved symbols and are linking dynamically to the C++ Standard | |
92 | library, and who thus must be careful to compile their application | |
93 | with a compiler that is compatible with the available C++ Standard | |
94 | library binary. In this case, compatible is defined with the equation | |
95 | above: given an application compiled with a given compiler ABI and | |
96 | library API, it will work correctly with a Standard C++ Library | |
97 | created with the same constraints. | |
98 | </para> | |
99 | ||
100 | <para> | |
101 | To use a specific version of the C++ ABI, one must use a | |
4394b61e | 102 | corresponding GNU C++ toolchain (i.e., g++ and libstdc++) that |
8a165db0 BK |
103 | implements the C++ ABI in question. |
104 | </para> | |
105 | ||
106 | </sect2> | |
107 | ||
108 | <sect2 id="abi.versioning" xreflabel="abi.versioning"> | |
109 | <title>Versioning</title> | |
110 | ||
111 | <para> The C++ interface has evolved throughout the history of the GNU | |
112 | C++ toolchain. With each release, various details have been changed so | |
113 | as to give distinct versions to the C++ interface. | |
114 | </para> | |
115 | ||
116 | <sect3 id="abi.versioning.goals" xreflabel="abi.versioning.goals"> | |
117 | <title>Goals</title> | |
118 | ||
119 | <para>Extending existing, stable ABIs. Versioning gives subsequent stable | |
120 | releases series libraries the ability to add new symbols and add | |
121 | functionality, all the while retaining backwards compatibility with | |
122 | the previous releases in the series. Note: the reverse is not true. It | |
123 | is not possible to take binaries linked with the latest version of a | |
124 | release series (if symbols have been added) and expect the initial | |
125 | release of the series to remain link compatible. | |
126 | </para> | |
127 | ||
128 | <para>Allows multiple, incompatible ABIs to coexist at the same time. | |
129 | </para> | |
130 | </sect3> | |
131 | ||
132 | <sect3 id="abi.versioning.history" xreflabel="abi.versioning.history"> | |
133 | <title>History</title> | |
134 | ||
135 | <para> | |
136 | How can this complexity be managed? What does C++ versioning mean? | |
137 | Because library and compiler changes often make binaries compiled | |
138 | with one version of the GNU tools incompatible with binaries | |
139 | compiled with other (either newer or older) versions of the same GNU | |
140 | tools, specific techniques are used to make managing this complexity | |
141 | easier. | |
142 | </para> | |
143 | ||
144 | <para> | |
145 | The following techniques are used: | |
146 | </para> | |
147 | ||
148 | <orderedlist> | |
149 | ||
150 | <listitem><para>Release versioning on the libgcc_s.so binary. </para> | |
151 | ||
152 | <para>This is implemented via file names and the ELF DT_SONAME | |
153 | mechanism (at least on ELF systems). It is versioned as follows: | |
154 | </para> | |
155 | ||
156 | <itemizedlist> | |
157 | <listitem><para>gcc-3.0.0: libgcc_s.so.1</para></listitem> | |
158 | <listitem><para>gcc-3.0.1: libgcc_s.so.1</para></listitem> | |
159 | <listitem><para>gcc-3.0.2: libgcc_s.so.1</para></listitem> | |
160 | <listitem><para>gcc-3.0.3: libgcc_s.so.1</para></listitem> | |
161 | <listitem><para>gcc-3.0.4: libgcc_s.so.1</para></listitem> | |
162 | <listitem><para>gcc-3.1.0: libgcc_s.so.1</para></listitem> | |
163 | <listitem><para>gcc-3.1.1: libgcc_s.so.1</para></listitem> | |
164 | <listitem><para>gcc-3.2.0: libgcc_s.so.1</para></listitem> | |
165 | <listitem><para>gcc-3.2.1: libgcc_s.so.1</para></listitem> | |
166 | <listitem><para>gcc-3.2.2: libgcc_s.so.1</para></listitem> | |
167 | <listitem><para>gcc-3.2.3: libgcc_s.so.1</para></listitem> | |
168 | <listitem><para>gcc-3.3.0: libgcc_s.so.1</para></listitem> | |
169 | <listitem><para>gcc-3.3.1: libgcc_s.so.1</para></listitem> | |
170 | <listitem><para>gcc-3.3.2: libgcc_s.so.1</para></listitem> | |
171 | <listitem><para>gcc-3.3.3: libgcc_s.so.1</para></listitem> | |
172 | <listitem><para>gcc-3.4.x, gcc-4.0.x, gcc-4.1.x, gcc-4.2.x: on m68k-linux and | |
173 | hppa-linux this is either libgcc_s.so.1 (when configuring | |
174 | <code>--with-sjlj-exceptions</code>) or libgcc_s.so.2. For all | |
175 | others, this is libgcc_s.so.1. </para> | |
176 | </listitem> | |
177 | </itemizedlist> | |
178 | ||
179 | </listitem> | |
180 | ||
181 | <listitem><para>Symbol versioning on the libgcc_s.so binary.</para> | |
182 | ||
183 | <para>It is versioned with the following labels and version | |
184 | definitions, where the version definition is the maximum for a | |
185 | particular release. Labels are cumulative. If a particular release | |
4394b61e | 186 | is not listed, it has the same version labels as the preceding |
8a165db0 BK |
187 | release.</para> |
188 | ||
189 | <para>This corresponds to the mapfile: gcc/libgcc-std.ver</para> | |
190 | <itemizedlist> | |
191 | <listitem><para>gcc-3.0.0: GCC_3.0</para></listitem> | |
192 | <listitem><para>gcc-3.3.0: GCC_3.3</para></listitem> | |
193 | <listitem><para>gcc-3.3.1: GCC_3.3.1</para></listitem> | |
194 | <listitem><para>gcc-3.3.2: GCC_3.3.2</para></listitem> | |
195 | <listitem><para>gcc-3.3.4: GCC_3.3.4</para></listitem> | |
196 | <listitem><para>gcc-3.4.0: GCC_3.4</para></listitem> | |
197 | <listitem><para>gcc-3.4.2: GCC_3.4.2</para></listitem> | |
198 | <listitem><para>gcc-3.4.4: GCC_3.4.4</para></listitem> | |
199 | <listitem><para>gcc-4.0.0: GCC_4.0.0</para></listitem> | |
200 | <listitem><para>gcc-4.1.0: GCC_4.1.0</para></listitem> | |
201 | <listitem><para>gcc-4.2.0: GCC_4.2.0</para></listitem> | |
202 | </itemizedlist> | |
203 | </listitem> | |
204 | ||
205 | <listitem><para>Release versioning on the libstdc++.so binary, implemented in the same was as the libgcc_s.so binary, above.</para> | |
206 | ||
207 | <para>It is versioned as follows: | |
208 | </para> | |
209 | <itemizedlist> | |
210 | <listitem><para>gcc-3.0.0: libstdc++.so.3.0.0</para></listitem> | |
211 | <listitem><para>gcc-3.0.1: libstdc++.so.3.0.1</para></listitem> | |
212 | <listitem><para>gcc-3.0.2: libstdc++.so.3.0.2</para></listitem> | |
213 | <listitem><para>gcc-3.0.3: libstdc++.so.3.0.2 (Error should be libstdc++.so.3.0.3)</para></listitem> | |
214 | <listitem><para>gcc-3.0.4: libstdc++.so.3.0.4</para></listitem> | |
215 | <listitem><para>gcc-3.1.0: libstdc++.so.4.0.0</para></listitem> | |
216 | <listitem><para>gcc-3.1.1: libstdc++.so.4.0.1</para></listitem> | |
217 | <listitem><para>gcc-3.2.0: libstdc++.so.5.0.0</para></listitem> | |
218 | <listitem><para>gcc-3.2.1: libstdc++.so.5.0.1</para></listitem> | |
219 | <listitem><para>gcc-3.2.2: libstdc++.so.5.0.2</para></listitem> | |
220 | <listitem><para>gcc-3.2.3: libstdc++.so.5.0.3 (Not strictly required)</para></listitem> | |
221 | <listitem><para>gcc-3.3.0: libstdc++.so.5.0.4</para></listitem> | |
222 | <listitem><para>gcc-3.3.1: libstdc++.so.5.0.5</para></listitem> | |
223 | <listitem><para>gcc-3.3.2: libstdc++.so.5.0.5</para></listitem> | |
224 | <listitem><para>gcc-3.3.3: libstdc++.so.5.0.5</para></listitem> | |
225 | <listitem><para>gcc-3.4.0: libstdc++.so.6.0.0</para></listitem> | |
226 | <listitem><para>gcc-3.4.1: libstdc++.so.6.0.1</para></listitem> | |
227 | <listitem><para>gcc-3.4.2: libstdc++.so.6.0.2</para></listitem> | |
228 | <listitem><para>gcc-3.4.3: libstdc++.so.6.0.3</para></listitem> | |
229 | <listitem><para>gcc-3.4.4: libstdc++.so.6.0.3</para></listitem> | |
230 | <listitem><para>gcc-3.4.5: libstdc++.so.6.0.3</para></listitem> | |
231 | <listitem><para>gcc-3.4.6: libstdc++.so.6.0.3</para></listitem> | |
232 | <listitem><para>gcc-4.0.0: libstdc++.so.6.0.4</para></listitem> | |
233 | <listitem><para>gcc-4.0.1: libstdc++.so.6.0.5</para></listitem> | |
234 | <listitem><para>gcc-4.0.2: libstdc++.so.6.0.6</para></listitem> | |
235 | <listitem><para>gcc-4.0.3: libstdc++.so.6.0.7</para></listitem> | |
236 | <listitem><para>gcc-4.1.0: libstdc++.so.6.0.7</para></listitem> | |
237 | <listitem><para>gcc-4.1.1: libstdc++.so.6.0.8</para></listitem> | |
238 | <listitem><para>gcc-4.1.2: libstdc++.so.6.0.8</para></listitem> | |
239 | <listitem><para>gcc-4.2.0: libstdc++.so.6.0.9</para></listitem> | |
240 | </itemizedlist> | |
241 | </listitem> | |
242 | ||
243 | <listitem><para>Symbol versioning on the libstdc++.so binary.</para> | |
244 | ||
245 | <para>mapfile: libstdc++/config/linker-map.gnu</para> | |
246 | <para>It is versioned with the following labels and version | |
247 | definitions, where the version definition is the maximum for a | |
248 | particular release. Note, only symbol which are newly introduced | |
249 | will use the maximum version definition. Thus, for release series | |
250 | with the same label, but incremented version definitions, the later | |
251 | release has both versions. (An example of this would be the | |
252 | gcc-3.2.1 release, which has GLIBCPP_3.2.1 for new symbols and | |
253 | GLIBCPP_3.2 for symbols that were introduced in the gcc-3.2.0 | |
254 | release.) If a particular release is not listed, it has the same | |
4394b61e | 255 | version labels as the preceding release. |
8a165db0 BK |
256 | </para> |
257 | <itemizedlist> | |
258 | <listitem><para>gcc-3.0.0: (Error, not versioned)</para></listitem> | |
259 | <listitem><para>gcc-3.0.1: (Error, not versioned)</para></listitem> | |
260 | <listitem><para>gcc-3.0.2: (Error, not versioned)</para></listitem> | |
261 | <listitem><para>gcc-3.0.3: (Error, not versioned)</para></listitem> | |
262 | <listitem><para>gcc-3.0.4: (Error, not versioned)</para></listitem> | |
263 | <listitem><para>gcc-3.1.0: GLIBCPP_3.1, CXXABI_1</para></listitem> | |
264 | <listitem><para>gcc-3.1.1: GLIBCPP_3.1, CXXABI_1</para></listitem> | |
265 | <listitem><para>gcc-3.2.0: GLIBCPP_3.2, CXXABI_1.2</para></listitem> | |
266 | <listitem><para>gcc-3.2.1: GLIBCPP_3.2.1, CXXABI_1.2</para></listitem> | |
267 | <listitem><para>gcc-3.2.2: GLIBCPP_3.2.2, CXXABI_1.2</para></listitem> | |
268 | <listitem><para>gcc-3.2.3: GLIBCPP_3.2.2, CXXABI_1.2</para></listitem> | |
269 | <listitem><para>gcc-3.3.0: GLIBCPP_3.2.2, CXXABI_1.2.1</para></listitem> | |
270 | <listitem><para>gcc-3.3.1: GLIBCPP_3.2.3, CXXABI_1.2.1</para></listitem> | |
271 | <listitem><para>gcc-3.3.2: GLIBCPP_3.2.3, CXXABI_1.2.1</para></listitem> | |
272 | <listitem><para>gcc-3.3.3: GLIBCPP_3.2.3, CXXABI_1.2.1</para></listitem> | |
273 | <listitem><para>gcc-3.4.0: GLIBCXX_3.4, CXXABI_1.3</para></listitem> | |
274 | <listitem><para>gcc-3.4.1: GLIBCXX_3.4.1, CXXABI_1.3</para></listitem> | |
275 | <listitem><para>gcc-3.4.2: GLIBCXX_3.4.2</para></listitem> | |
276 | <listitem><para>gcc-3.4.3: GLIBCXX_3.4.3</para></listitem> | |
277 | <listitem><para>gcc-4.0.0: GLIBCXX_3.4.4, CXXABI_1.3.1</para></listitem> | |
278 | <listitem><para>gcc-4.0.1: GLIBCXX_3.4.5</para></listitem> | |
279 | <listitem><para>gcc-4.0.2: GLIBCXX_3.4.6</para></listitem> | |
280 | <listitem><para>gcc-4.0.3: GLIBCXX_3.4.7</para></listitem> | |
281 | <listitem><para>gcc-4.1.1: GLIBCXX_3.4.8</para></listitem> | |
282 | <listitem><para>gcc-4.2.0: GLIBCXX_3.4.9</para></listitem> | |
283 | </itemizedlist> | |
284 | </listitem> | |
285 | ||
286 | <listitem> | |
287 | <para>Incremental bumping of a compiler pre-defined macro, | |
288 | __GXX_ABI_VERSION. This macro is defined as the version of the | |
289 | compiler v3 ABI, with g++ 3.0.x being version 100. This macro will | |
290 | be automatically defined whenever g++ is used (the curious can | |
291 | test this by invoking g++ with the '-v' flag.) | |
292 | </para> | |
293 | ||
294 | <para> | |
295 | This macro was defined in the file "lang-specs.h" in the gcc/cp directory. | |
296 | Later versions defined it in "c-common.c" in the gcc directory, and from | |
297 | G++ 3.4 it is defined in c-cppbuiltin.c and its value determined by the | |
298 | '-fabi-version' command line option. | |
299 | </para> | |
300 | ||
301 | <para> | |
302 | It is versioned as follows, where 'n' is given by '-fabi-version=n': | |
303 | </para> | |
304 | <itemizedlist> | |
305 | <listitem><para>gcc-3.0.x: 100</para></listitem> | |
306 | <listitem><para>gcc-3.1.x: 100 (Error, should be 101)</para></listitem> | |
307 | <listitem><para>gcc-3.2.x: 102</para></listitem> | |
308 | <listitem><para>gcc-3.3.x: 102</para></listitem> | |
309 | <listitem><para>gcc-3.4.x, gcc-4.0.x, gcc-4.1.x, gcc-4.2.x: 102 (when n=1)</para></listitem> | |
310 | <listitem><para>gcc-3.4.x, gcc-4.0.x, gcc-4.1.x, gcc-4.2.x: 1000 + n (when n>1)</para></listitem> | |
311 | <listitem><para>gcc-3.4.x, gcc-4.0.x, gcc-4.1.x, gcc-4.2.x: 999999 (when n=0)</para></listitem> | |
312 | </itemizedlist> | |
313 | <para></para> | |
314 | </listitem> | |
315 | ||
316 | <listitem> | |
317 | <para>Changes to the default compiler option for | |
318 | <code>-fabi-version</code>. | |
319 | </para> | |
320 | <para> | |
321 | It is versioned as follows: | |
322 | </para> | |
323 | <itemizedlist> | |
324 | <listitem><para>gcc-3.0.x: (Error, not versioned) </para></listitem> | |
325 | <listitem><para>gcc-3.1.x: (Error, not versioned) </para></listitem> | |
326 | <listitem><para>gcc-3.2.x: <code>-fabi-version=1</code></para></listitem> | |
327 | <listitem><para>gcc-3.3.x: <code>-fabi-version=1</code></para></listitem> | |
328 | <listitem><para>gcc-3.4.x, gcc-4.0.x, gcc-4.1.x, gcc-4.2.x: <code>-fabi-version=2</code></para></listitem> | |
329 | </itemizedlist> | |
330 | <para></para> | |
331 | </listitem> | |
332 | ||
333 | <listitem> | |
334 | <para>Incremental bumping of a library pre-defined macro. For releases | |
335 | before 3.4.0, the macro is __GLIBCPP__. For later releases, it's | |
336 | __GLIBCXX__. (The libstdc++ project generously changed from CPP to | |
337 | CXX throughout its source to allow the "C" pre-processor the CPP | |
338 | macro namespace.) These macros are defined as the date the library | |
339 | was released, in compressed ISO date format, as an unsigned long. | |
340 | </para> | |
341 | ||
342 | <para> | |
343 | This macro is defined in the file "c++config" in the | |
344 | "libstdc++/include/bits" directory. (Up to gcc-4.1.0, it was | |
345 | changed every night by an automated script. Since gcc-4.1.0, it is | |
346 | the same value as gcc/DATESTAMP.) | |
347 | </para> | |
348 | <para> | |
349 | It is versioned as follows: | |
350 | </para> | |
351 | <itemizedlist> | |
352 | <listitem><para>gcc-3.0.0: 20010615</para></listitem> | |
353 | <listitem><para>gcc-3.0.1: 20010819</para></listitem> | |
354 | <listitem><para>gcc-3.0.2: 20011023</para></listitem> | |
355 | <listitem><para>gcc-3.0.3: 20011220</para></listitem> | |
356 | <listitem><para>gcc-3.0.4: 20020220</para></listitem> | |
357 | <listitem><para>gcc-3.1.0: 20020514</para></listitem> | |
358 | <listitem><para>gcc-3.1.1: 20020725</para></listitem> | |
359 | <listitem><para>gcc-3.2.0: 20020814</para></listitem> | |
360 | <listitem><para>gcc-3.2.1: 20021119</para></listitem> | |
361 | <listitem><para>gcc-3.2.2: 20030205</para></listitem> | |
362 | <listitem><para>gcc-3.2.3: 20030422</para></listitem> | |
363 | <listitem><para>gcc-3.3.0: 20030513</para></listitem> | |
364 | <listitem><para>gcc-3.3.1: 20030804</para></listitem> | |
365 | <listitem><para>gcc-3.3.2: 20031016</para></listitem> | |
366 | <listitem><para>gcc-3.3.3: 20040214</para></listitem> | |
367 | <listitem><para>gcc-3.4.0: 20040419</para></listitem> | |
368 | <listitem><para>gcc-3.4.1: 20040701</para></listitem> | |
369 | <listitem><para>gcc-3.4.2: 20040906</para></listitem> | |
370 | <listitem><para>gcc-3.4.3: 20041105</para></listitem> | |
371 | <listitem><para>gcc-3.4.4: 20050519</para></listitem> | |
372 | <listitem><para>gcc-3.4.5: 20051201</para></listitem> | |
373 | <listitem><para>gcc-3.4.6: 20060306</para></listitem> | |
374 | <listitem><para>gcc-4.0.0: 20050421</para></listitem> | |
375 | <listitem><para>gcc-4.0.1: 20050707</para></listitem> | |
376 | <listitem><para>gcc-4.0.2: 20050921</para></listitem> | |
377 | <listitem><para>gcc-4.0.3: 20060309</para></listitem> | |
378 | <listitem><para>gcc-4.1.0: 20060228</para></listitem> | |
379 | <listitem><para>gcc-4.1.1: 20060524</para></listitem> | |
380 | <listitem><para>gcc-4.1.2: 20070214</para></listitem> | |
381 | <listitem><para>gcc-4.2.0: 20070514</para></listitem> | |
382 | </itemizedlist> | |
383 | <para></para> | |
384 | </listitem> | |
385 | ||
386 | <listitem> | |
387 | <para> | |
388 | Incremental bumping of a library pre-defined macro, | |
389 | _GLIBCPP_VERSION. This macro is defined as the released version of | |
390 | the library, as a string literal. This is only implemented in | |
391 | gcc-3.1.0 releases and higher, and is deprecated in 3.4 (where it | |
392 | is called _GLIBCXX_VERSION). | |
393 | </para> | |
394 | ||
395 | <para> | |
396 | This macro is defined in the file "c++config" in the | |
397 | "libstdc++/include/bits" directory and is generated | |
398 | automatically by autoconf as part of the configure-time generation | |
399 | of config.h. | |
400 | </para> | |
401 | ||
402 | <para> | |
403 | It is versioned as follows: | |
404 | </para> | |
405 | <itemizedlist> | |
406 | <listitem><para>gcc-3.0.0: "3.0.0"</para></listitem> | |
407 | <listitem><para>gcc-3.0.1: "3.0.0" (Error, should be "3.0.1")</para></listitem> | |
408 | <listitem><para>gcc-3.0.2: "3.0.0" (Error, should be "3.0.2")</para></listitem> | |
409 | <listitem><para>gcc-3.0.3: "3.0.0" (Error, should be "3.0.3")</para></listitem> | |
410 | <listitem><para>gcc-3.0.4: "3.0.0" (Error, should be "3.0.4")</para></listitem> | |
411 | <listitem><para>gcc-3.1.0: "3.1.0"</para></listitem> | |
412 | <listitem><para>gcc-3.1.1: "3.1.1"</para></listitem> | |
413 | <listitem><para>gcc-3.2.0: "3.2"</para></listitem> | |
414 | <listitem><para>gcc-3.2.1: "3.2.1"</para></listitem> | |
415 | <listitem><para>gcc-3.2.2: "3.2.2"</para></listitem> | |
416 | <listitem><para>gcc-3.2.3: "3.2.3"</para></listitem> | |
417 | <listitem><para>gcc-3.3.0: "3.3"</para></listitem> | |
418 | <listitem><para>gcc-3.3.1: "3.3.1"</para></listitem> | |
419 | <listitem><para>gcc-3.3.2: "3.3.2"</para></listitem> | |
420 | <listitem><para>gcc-3.3.3: "3.3.3"</para></listitem> | |
421 | <listitem><para>gcc-3.4.x: "version-unused"</para></listitem> | |
422 | <listitem><para>gcc-4.0.x: "version-unused"</para></listitem> | |
423 | <listitem><para>gcc-4.1.x: "version-unused"</para></listitem> | |
424 | <listitem><para>gcc-4.2.x: "version-unused"</para></listitem> | |
425 | </itemizedlist> | |
426 | <para></para> | |
427 | </listitem> | |
428 | ||
429 | <listitem> | |
430 | <para> | |
431 | Matching each specific C++ compiler release to a specific set of | |
432 | C++ include files. This is only implemented in gcc-3.1.1 releases | |
433 | and higher. | |
434 | </para> | |
435 | <para> | |
436 | All C++ includes are installed in include/c++, then nest in a | |
437 | directory hierarchy corresponding to the C++ compiler's released | |
438 | version. This version corresponds to the variable "gcc_version" in | |
439 | "libstdc++/acinclude.m4," and more details can be found in that | |
440 | file's macro GLIBCXX_CONFIGURE (GLIBCPP_CONFIGURE before gcc-3.4.0). | |
441 | </para> | |
442 | <para> | |
443 | C++ includes are versioned as follows: | |
444 | </para> | |
445 | <itemizedlist> | |
446 | <listitem><para>gcc-3.0.0: include/g++-v3</para></listitem> | |
447 | <listitem><para>gcc-3.0.1: include/g++-v3</para></listitem> | |
448 | <listitem><para>gcc-3.0.2: include/g++-v3</para></listitem> | |
449 | <listitem><para>gcc-3.0.3: include/g++-v3</para></listitem> | |
450 | <listitem><para>gcc-3.0.4: include/g++-v3</para></listitem> | |
451 | <listitem><para>gcc-3.1.0: include/g++-v3</para></listitem> | |
452 | <listitem><para>gcc-3.1.1: include/c++/3.1.1</para></listitem> | |
453 | <listitem><para>gcc-3.2.0: include/c++/3.2</para></listitem> | |
454 | <listitem><para>gcc-3.2.1: include/c++/3.2.1</para></listitem> | |
455 | <listitem><para>gcc-3.2.2: include/c++/3.2.2</para></listitem> | |
456 | <listitem><para>gcc-3.2.3: include/c++/3.2.3</para></listitem> | |
457 | <listitem><para>gcc-3.3.0: include/c++/3.3</para></listitem> | |
458 | <listitem><para>gcc-3.3.1: include/c++/3.3.1</para></listitem> | |
459 | <listitem><para>gcc-3.3.2: include/c++/3.3.2</para></listitem> | |
460 | <listitem><para>gcc-3.3.3: include/c++/3.3.3</para></listitem> | |
461 | <listitem><para>gcc-3.4.0: include/c++/3.4.0</para></listitem> | |
462 | <listitem><para>gcc-3.4.1: include/c++/3.4.1</para></listitem> | |
463 | <listitem><para>gcc-3.4.2: include/c++/3.4.2</para></listitem> | |
464 | <listitem><para>gcc-3.4.3: include/c++/3.4.3</para></listitem> | |
465 | <listitem><para>gcc-3.4.4: include/c++/3.4.4</para></listitem> | |
466 | <listitem><para>gcc-3.4.5: include/c++/3.4.5</para></listitem> | |
467 | <listitem><para>gcc-3.4.6: include/c++/3.4.6</para></listitem> | |
468 | <listitem><para>gcc-4.0.0: include/c++/4.0.0</para></listitem> | |
469 | <listitem><para>gcc-4.0.1: include/c++/4.0.1</para></listitem> | |
470 | <listitem><para>gcc-4.0.2: include/c++/4.0.2</para></listitem> | |
471 | <listitem><para>gcc-4.0.3: include/c++/4.0.3</para></listitem> | |
472 | <listitem><para>gcc-4.1.0: include/c++/4.1.0</para></listitem> | |
473 | <listitem><para>gcc-4.1.1: include/c++/4.1.1</para></listitem> | |
474 | <listitem><para>gcc-4.1.2: include/c++/4.1.2</para></listitem> | |
475 | <listitem><para>gcc-4.2.0: include/c++/4.2.0</para></listitem> | |
476 | </itemizedlist> | |
477 | <para></para> | |
478 | </listitem> | |
479 | </orderedlist> | |
480 | ||
481 | <para> | |
482 | Taken together, these techniques can accurately specify interface | |
483 | and implementation changes in the GNU C++ tools themselves. Used | |
484 | properly, they allow both the GNU C++ tools implementation, and | |
485 | programs using them, an evolving yet controlled development that | |
486 | maintains backward compatibility. | |
487 | </para> | |
488 | ||
489 | ||
490 | </sect3> | |
491 | ||
492 | <sect3 id="abi.versioning.prereq" xreflabel="abi.versioning.prereq"> | |
493 | <title>Prerequisites</title> | |
494 | <para> | |
495 | Minimum environment that supports a versioned ABI: A supported | |
496 | dynamic linker, a GNU linker of sufficient vintage to understand | |
497 | demangled C++ name globbing (ld), a shared executable compiled | |
498 | with g++, and shared libraries (libgcc_s, libstdc++) compiled by | |
499 | a compiler (g++) with a compatible ABI. Phew. | |
500 | </para> | |
501 | ||
502 | <para> | |
503 | On top of all that, an additional constraint: libstdc++ did not | |
504 | attempt to version symbols (or age gracefully, really) until | |
505 | version 3.1.0. | |
506 | </para> | |
507 | ||
508 | <para> | |
509 | Most modern Linux and BSD versions, particularly ones using | |
510 | gcc-3.1.x tools and more recent vintages, will meet the | |
511 | requirements above. | |
512 | </para> | |
513 | </sect3> | |
514 | ||
515 | <sect3 id="abi.versioning.config" xreflabel="abi.versioning.config"> | |
516 | <title>Configuring</title> | |
517 | ||
518 | <para> | |
519 | It turns out that most of the configure options that change | |
520 | default behavior will impact the mangled names of exported | |
521 | symbols, and thus impact versioning and compatibility. | |
522 | </para> | |
523 | ||
524 | <para> | |
525 | For more information on configure options, including ABI | |
526 | impacts, see: | |
527 | http://gcc.gnu.org/onlinedocs/libstdc++/configopts.html | |
528 | </para> | |
529 | ||
530 | <para> | |
531 | There is one flag that explicitly deals with symbol versioning: | |
532 | --enable-symvers. | |
533 | </para> | |
534 | ||
535 | <para> | |
536 | In particular, libstdc++/acinclude.m4 has a macro called | |
537 | GLIBCXX_ENABLE_SYMVERS that defaults to yes (or the argument | |
538 | passed in via --enable-symvers=foo). At that point, the macro | |
539 | attempts to make sure that all the requirement for symbol | |
540 | versioning are in place. For more information, please consult | |
541 | acinclude.m4. | |
542 | </para> | |
543 | </sect3> | |
544 | ||
545 | <sect3 id="abi.versioning.active" xreflabel="abi.versioning.active"> | |
546 | <title>Checking Active</title> | |
547 | ||
548 | <para> | |
549 | When the GNU C++ library is being built with symbol versioning | |
550 | on, you should see the following at configure time for | |
551 | libstdc++: | |
552 | </para> | |
553 | ||
554 | <screen> | |
555 | <computeroutput> | |
556 | checking versioning on shared library symbols... gnu | |
557 | </computeroutput> | |
558 | </screen> | |
559 | ||
560 | <para> | |
561 | If you don't see this line in the configure output, or if this line | |
562 | appears but the last word is 'no', then you are out of luck. | |
563 | </para> | |
564 | ||
565 | <para> | |
566 | If the compiler is pre-installed, a quick way to test is to compile | |
567 | the following (or any) simple C++ file and link it to the shared | |
568 | libstdc++ library: | |
569 | </para> | |
570 | ||
571 | <programlisting> | |
572 | #include <iostream> | |
573 | ||
574 | int main() | |
575 | { std::cout << "hello" << std::endl; return 0; } | |
576 | ||
577 | %g++ hello.cc -o hello.out | |
578 | ||
579 | %ldd hello.out | |
580 | libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x00764000) | |
581 | libm.so.6 => /lib/tls/libm.so.6 (0x004a8000) | |
582 | libgcc_s.so.1 => /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x40016000) | |
583 | libc.so.6 => /lib/tls/libc.so.6 (0x0036d000) | |
584 | /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00355000) | |
585 | ||
586 | %nm hello.out | |
587 | </programlisting> | |
588 | ||
589 | <para> | |
590 | If you see symbols in the resulting output with "GLIBCXX_3" as part | |
591 | of the name, then the executable is versioned. Here's an example: | |
592 | </para> | |
593 | ||
594 | <para> | |
595 | <code>U _ZNSt8ios_base4InitC1Ev@@GLIBCXX_3.4</code> | |
596 | </para> | |
597 | ||
598 | </sect3> | |
599 | </sect2> | |
600 | ||
601 | <sect2 id="abi.changes_allowed" xreflabel="abi.changes_allowed"> | |
602 | <title>Allowed Changes</title> | |
603 | ||
604 | <para> | |
605 | The following will cause the library minor version number to | |
606 | increase, say from "libstdc++.so.3.0.4" to "libstdc++.so.3.0.5". | |
607 | </para> | |
608 | <orderedlist> | |
609 | <listitem><para>Adding an exported global or static data member</para></listitem> | |
610 | <listitem><para>Adding an exported function, static or non-virtual member function</para></listitem> | |
611 | <listitem><para>Adding an exported symbol or symbols by additional instantiations</para></listitem> | |
612 | </orderedlist> | |
613 | <para> | |
614 | Other allowed changes are possible. | |
615 | </para> | |
616 | ||
617 | </sect2> | |
618 | ||
619 | <sect2 id="abi.changes_no" xreflabel="abi.changes_no"> | |
620 | <title>Prohibited Changes</title> | |
621 | ||
622 | <para> | |
623 | The following non-exhaustive list will cause the library major version | |
624 | number to increase, say from "libstdc++.so.3.0.4" to | |
625 | "libstdc++.so.4.0.0". | |
626 | </para> | |
627 | ||
628 | <orderedlist> | |
629 | <listitem><para>Changes in the gcc/g++ compiler ABI</para></listitem> | |
630 | <listitem><para>Changing size of an exported symbol</para></listitem> | |
631 | <listitem><para>Changing alignment of an exported symbol</para></listitem> | |
632 | <listitem><para>Changing the layout of an exported symbol</para></listitem> | |
633 | <listitem><para>Changing mangling on an exported symbol</para></listitem> | |
634 | <listitem><para>Deleting an exported symbol</para></listitem> | |
635 | <listitem><para>Changing the inheritance properties of a type by adding or removing | |
636 | base classes</para></listitem> | |
637 | <listitem><para> | |
638 | Changing the size, alignment, or layout of types | |
639 | specified in the C++ standard. These may not necessarily be | |
640 | instantiated or otherwise exported in the library binary, and | |
641 | include all the required locale facets, as well as things like | |
642 | std::basic_streambuf, et al. | |
643 | </para></listitem> | |
644 | ||
645 | <listitem><para> Adding an explicit copy constructor or destructor to a | |
646 | class that would otherwise have implicit versions. This will change | |
647 | the way the compiler deals with this class in by-value return | |
648 | statements or parameters: instead of being passing instances of this | |
649 | class in registers, the compiler will be forced to use memory. See <ulink url="http://www.codesourcery.com/cxx-abi/abi.html#calls"> this part</ulink> | |
650 | of the C++ ABI documentation for further details. | |
651 | </para></listitem> | |
652 | ||
653 | </orderedlist> | |
654 | ||
655 | </sect2> | |
656 | ||
657 | ||
658 | ||
659 | <sect2 id="abi.impl" xreflabel="abi.impl"> | |
660 | <title>Implementation</title> | |
661 | ||
662 | <orderedlist> | |
663 | <listitem> | |
664 | <para> | |
665 | Separation of interface and implementation | |
666 | </para> | |
667 | <para> | |
668 | This is accomplished by two techniques that separate the API from | |
669 | the ABI: forcing undefined references to link against a library | |
670 | binary for definitions. | |
671 | </para> | |
672 | ||
673 | <variablelist> | |
674 | <varlistentry> | |
675 | <term>Include files have declarations, source files have defines</term> | |
676 | ||
677 | <listitem> | |
678 | <para> | |
679 | For non-templatized types, such as much of <code>class | |
680 | locale</code>, the appropriate standard C++ include, say | |
681 | <code>locale</code>, can contain full declarations, while | |
682 | various source files (say <code> locale.cc, locale_init.cc, | |
683 | localename.cc</code>) contain definitions. | |
684 | </para> | |
685 | </listitem> | |
686 | </varlistentry> | |
687 | ||
688 | <varlistentry> | |
689 | <term>Extern template on required types</term> | |
690 | ||
691 | <listitem> | |
692 | <para> | |
693 | For parts of the standard that have an explicit list of | |
694 | required instantiations, the GNU extension syntax <code> extern | |
695 | template </code> can be used to control where template | |
696 | definitions reside. By marking required instantiations as | |
697 | <code> extern template </code> in include files, and providing | |
698 | explicit instantiations in the appropriate instantiation files, | |
699 | non-inlined template functions can be versioned. This technique | |
700 | is mostly used on parts of the standard that require <code> | |
701 | char</code> and <code> wchar_t</code> instantiations, and | |
702 | includes <code> basic_string</code>, the locale facets, and the | |
703 | types in <code> iostreams</code>. | |
704 | </para> | |
705 | </listitem> | |
706 | </varlistentry> | |
707 | ||
708 | </variablelist> | |
709 | ||
710 | <para> | |
711 | In addition, these techniques have the additional benefit that they | |
712 | reduce binary size, which can increase runtime performance. | |
713 | </para> | |
714 | </listitem> | |
715 | ||
716 | <listitem> | |
717 | <para> | |
718 | Namespaces linking symbol definitions to export mapfiles | |
719 | </para> | |
720 | <para> | |
721 | All symbols in the shared library binary are processed by a | |
722 | linker script at build time that either allows or disallows | |
723 | external linkage. Because of this, some symbols, regardless of | |
724 | normal C/C++ linkage, are not visible. Symbols that are internal | |
725 | have several appealing characteristics: by not exporting the | |
726 | symbols, there are no relocations when the shared library is | |
727 | started and thus this makes for faster runtime loading | |
728 | performance by the underlying dynamic loading mechanism. In | |
729 | addition, they have the possibility of changing without impacting | |
730 | ABI compatibility. | |
731 | </para> | |
732 | ||
733 | <para>The following namespaces are transformed by the mapfile:</para> | |
734 | ||
735 | <variablelist> | |
736 | ||
737 | <varlistentry> | |
738 | <term><code>namespace std</code></term> | |
739 | <listitem><para> Defaults to exporting all symbols in label | |
4394b61e | 740 | <code>GLIBCXX</code> that do not begin with an underscore, i.e., |
8a165db0 BK |
741 | <code>__test_func</code> would not be exported by default. Select |
742 | exceptional symbols are allowed to be visible.</para></listitem> | |
743 | </varlistentry> | |
744 | ||
745 | <varlistentry> | |
746 | <term><code>namespace __gnu_cxx</code></term> | |
747 | <listitem><para> Defaults to not exporting any symbols in label | |
748 | <code>GLIBCXX</code>, select items are allowed to be visible.</para></listitem> | |
749 | </varlistentry> | |
750 | ||
751 | <varlistentry> | |
752 | <term><code>namespace __gnu_internal</code></term> | |
753 | <listitem><para> Defaults to not exported, no items are allowed to be visible.</para></listitem> | |
754 | </varlistentry> | |
755 | ||
756 | <varlistentry> | |
757 | <term><code>namespace __cxxabiv1</code>, aliased to <code> namespace abi</code></term> | |
758 | <listitem><para> Defaults to not exporting any symbols in label | |
759 | <code>CXXABI</code>, select items are allowed to be visible.</para></listitem> | |
760 | </varlistentry> | |
761 | ||
762 | </variablelist> | |
763 | <para> | |
764 | </para> | |
765 | </listitem> | |
766 | ||
767 | <listitem><para>Freezing the API</para> | |
768 | <para>Disallowed changes, as above, are not made on a stable release | |
769 | branch. Enforcement tends to be less strict with GNU extensions that | |
770 | standard includes.</para> | |
771 | </listitem> | |
772 | </orderedlist> | |
773 | ||
774 | </sect2> | |
775 | ||
776 | <sect2 id="abi.testing" xreflabel="abi.testing"> | |
777 | <title>Testing</title> | |
778 | ||
779 | <sect3 id="abi.testing.single" xreflabel="abi.testing.single"> | |
780 | <title>Single ABI Testing</title> | |
781 | ||
782 | <para> | |
783 | Testing for GNU C++ ABI changes is composed of two distinct | |
784 | areas: testing the C++ compiler (g++) for compiler changes, and | |
785 | testing the C++ library (libstdc++) for library changes. | |
786 | </para> | |
787 | ||
788 | <para> | |
789 | Testing the C++ compiler ABI can be done various ways. | |
790 | </para> | |
791 | ||
792 | <para> | |
793 | One. Intel ABI checker. More information can be obtained <ulink | |
794 | url="http://developer.intel.com/software/products/opensource/">here.</ulink> | |
795 | </para> | |
796 | ||
797 | <para> | |
798 | Two. | |
799 | The second is yet unreleased, but has been announced on the gcc | |
800 | mailing list. It is yet unspecified if these tools will be freely | |
801 | available, and able to be included in a GNU project. Please contact | |
802 | Mark Mitchell (mark@codesourcery.com) for more details, and current | |
803 | status. | |
804 | </para> | |
805 | ||
806 | <para> | |
807 | Three. | |
808 | Involves using the vlad.consistency test framework. This has also been | |
809 | discussed on the gcc mailing lists. | |
810 | </para> | |
811 | ||
812 | <para> | |
813 | Testing the C++ library ABI can also be done various ways. | |
814 | </para> | |
815 | ||
816 | <para> | |
817 | One. | |
818 | (Brendan Kehoe, Jeff Law suggestion to run 'make check-c++' two ways, | |
819 | one with a new compiler and an old library, and the other with an old | |
820 | compiler and a new library, and look for testsuite regressions) | |
821 | </para> | |
822 | ||
823 | <para> | |
824 | Details on how to set this kind of test up can be found here: | |
825 | http://gcc.gnu.org/ml/gcc/2002-08/msg00142.html | |
826 | </para> | |
827 | ||
828 | <para> | |
829 | Two. | |
830 | Use the 'make check-abi' rule in the libstdc++ Makefile. | |
831 | </para> | |
832 | ||
833 | <para> | |
834 | This is a proactive check the library ABI. Currently, exported symbol | |
835 | names that are either weak or defined are checked against a last known | |
836 | good baseline. Currently, this baseline is keyed off of 3.4.0 | |
837 | binaries, as this was the last time the .so number was incremented. In | |
838 | addition, all exported names are demangled, and the exported objects | |
839 | are checked to make sure they are the same size as the same object in | |
840 | the baseline. | |
841 | ||
842 | Notice that each baseline is relative to a <emphasis>default</emphasis> | |
843 | configured library and compiler: in particular, if options such as | |
844 | --enable-clocale, or --with-cpu, in case of multilibs, are used at | |
845 | configure time, the check may fail, either because of substantive | |
846 | differences or because of limitations of the current checking | |
847 | machinery. | |
848 | </para> | |
849 | ||
850 | <para> | |
851 | This dataset is insufficient, yet a start. Also needed is a | |
852 | comprehensive check for all user-visible types part of the standard | |
853 | library for sizeof() and alignof() changes. | |
854 | </para> | |
855 | ||
856 | <para> | |
857 | Verifying compatible layouts of objects is not even attempted. It | |
858 | should be possible to use sizeof, alignof, and offsetof to compute | |
859 | offsets for each structure and type in the standard library, saving to | |
860 | another datafile. Then, compute this in a similar way for new | |
861 | binaries, and look for differences. | |
862 | </para> | |
863 | ||
864 | <para> | |
865 | Another approach might be to use the -fdump-class-hierarchy flag to | |
866 | get information. However, currently this approach gives insufficient | |
867 | data for use in library testing, as class data members, their offsets, | |
868 | and other detailed data is not displayed with this flag. | |
869 | (See g++/7470 on how this was used to find bugs.) | |
870 | </para> | |
871 | ||
872 | <para> | |
873 | Perhaps there are other C++ ABI checkers. If so, please notify | |
874 | us. We'd like to know about them! | |
875 | </para> | |
876 | ||
877 | </sect3> | |
878 | <sect3 id="abi.testing.multi" xreflabel="abi.testing.multi"> | |
879 | <title>Multiple ABI Testing</title> | |
880 | <para> | |
881 | A "C" application, dynamically linked to two shared libraries, liba, | |
882 | libb. The dependent library liba is C++ shared library compiled with | |
883 | gcc-3.3.x, and uses io, exceptions, locale, etc. The dependent library | |
884 | libb is a C++ shared library compiled with gcc-3.4.x, and also uses io, | |
885 | exceptions, locale, etc. | |
886 | </para> | |
887 | ||
888 | <para> As above, libone is constructed as follows: </para> | |
889 | <programlisting> | |
890 | %$bld/H-x86-gcc-3.4.0/bin/g++ -fPIC -DPIC -c a.cc | |
891 | ||
892 | %$bld/H-x86-gcc-3.4.0/bin/g++ -shared -Wl,-soname -Wl,libone.so.1 -Wl,-O1 -Wl,-z,defs a.o -o libone.so.1.0.0 | |
893 | ||
894 | %ln -s libone.so.1.0.0 libone.so | |
895 | ||
896 | %$bld/H-x86-gcc-3.4.0/bin/g++ -c a.cc | |
897 | ||
898 | %ar cru libone.a a.o | |
899 | </programlisting> | |
900 | ||
901 | <para> And, libtwo is constructed as follows: </para> | |
902 | ||
903 | <programlisting> | |
904 | %$bld/H-x86-gcc-3.3.3/bin/g++ -fPIC -DPIC -c b.cc | |
905 | ||
906 | %$bld/H-x86-gcc-3.3.3/bin/g++ -shared -Wl,-soname -Wl,libtwo.so.1 -Wl,-O1 -Wl,-z,defs b.o -o libtwo.so.1.0.0 | |
907 | ||
908 | %ln -s libtwo.so.1.0.0 libtwo.so | |
909 | ||
910 | %$bld/H-x86-gcc-3.3.3/bin/g++ -c b.cc | |
911 | ||
912 | %ar cru libtwo.a b.o | |
913 | </programlisting> | |
914 | ||
915 | <para> ...with the resulting libraries looking like </para> | |
916 | ||
917 | <screen> | |
918 | <computeroutput> | |
919 | %ldd libone.so.1.0.0 | |
920 | libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x40016000) | |
921 | libm.so.6 => /lib/tls/libm.so.6 (0x400fa000) | |
922 | libgcc_s.so.1 => /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x4011c000) | |
923 | libc.so.6 => /lib/tls/libc.so.6 (0x40125000) | |
924 | /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00355000) | |
925 | ||
926 | %ldd libtwo.so.1.0.0 | |
927 | libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40027000) | |
928 | libm.so.6 => /lib/tls/libm.so.6 (0x400e1000) | |
929 | libgcc_s.so.1 => /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x40103000) | |
930 | libc.so.6 => /lib/tls/libc.so.6 (0x4010c000) | |
931 | /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00355000) | |
932 | </computeroutput> | |
933 | </screen> | |
934 | ||
935 | <para> | |
936 | Then, the "C" compiler is used to compile a source file that uses | |
937 | functions from each library. | |
938 | </para> | |
939 | <programlisting> | |
940 | gcc test.c -g -O2 -L. -lone -ltwo /usr/lib/libstdc++.so.5 /usr/lib/libstdc++.so.6 | |
941 | </programlisting> | |
942 | ||
943 | <para> | |
944 | Which gives the expected: | |
945 | </para> | |
946 | ||
947 | <screen> | |
948 | <computeroutput> | |
949 | %ldd a.out | |
950 | libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x00764000) | |
951 | libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x40015000) | |
952 | libc.so.6 => /lib/tls/libc.so.6 (0x0036d000) | |
953 | libm.so.6 => /lib/tls/libm.so.6 (0x004a8000) | |
954 | libgcc_s.so.1 => /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x400e5000) | |
955 | /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00355000) | |
956 | </computeroutput> | |
957 | </screen> | |
958 | ||
959 | <para> | |
960 | This resulting binary, when executed, will be able to safely use | |
961 | code from both liba, and the dependent libstdc++.so.6, and libb, | |
962 | with the dependent libstdc++.so.5. | |
963 | </para> | |
964 | </sect3> | |
965 | </sect2> | |
966 | ||
967 | <sect2 id="abi.issues" xreflabel="abi.issues"> | |
968 | <title>Outstanding Issues</title> | |
969 | ||
970 | <para> | |
971 | Some features in the C++ language make versioning especially | |
972 | difficult. In particular, compiler generated constructs such as | |
973 | implicit instantiations for templates, typeinfo information, and | |
974 | virtual tables all may cause ABI leakage across shared library | |
4394b61e | 975 | boundaries. Because of this, mixing C++ ABIs is not recommended at |
8a165db0 BK |
976 | this time. |
977 | </para> | |
978 | ||
979 | <para> | |
980 | For more background on this issue, see these bugzilla entries: | |
981 | </para> | |
982 | ||
983 | <para> | |
984 | <ulink url="http://gcc.gnu.org/PR24660">24660: versioning weak symbols in libstdc++</ulink> | |
985 | </para> | |
986 | ||
987 | <para> | |
988 | <ulink url="http://gcc.gnu.org/PR19664">19664: libstdc++ headers should have pop/push of the visibility around the declarations</ulink> | |
989 | </para> | |
990 | ||
991 | </sect2> | |
992 | ||
993 | <bibliography id="abi.biblio" xreflabel="abi.biblio"> | |
994 | <title>Bibliography</title> | |
995 | ||
996 | <biblioentry> | |
997 | <title> | |
998 | ABIcheck, a vague idea of checking ABI compatibility | |
999 | </title> | |
1000 | ||
1001 | <biblioid> | |
1002 | <ulink url="http://abicheck.sourceforge.net/"> | |
1003 | </ulink> | |
1004 | </biblioid> | |
1005 | </biblioentry> | |
1006 | ||
1007 | <biblioentry> | |
1008 | <title> | |
1009 | C++ ABI Reference | |
1010 | </title> | |
1011 | ||
1012 | <biblioid> | |
1013 | <ulink url="http://www.codesourcery.com/cxx-abi"> | |
1014 | </ulink> | |
1015 | </biblioid> | |
1016 | </biblioentry> | |
1017 | ||
1018 | <biblioentry> | |
1019 | <title> | |
1020 | IntelĀ® Compilers for Linux* -Compatibility with the GNU Compilers | |
1021 | </title> | |
1022 | ||
1023 | <biblioid> | |
1024 | <ulink url="http://developer.intel.com/software/products/compilers/techtopics/LinuxCompilersCompatibility.htm"> | |
1025 | </ulink> | |
1026 | </biblioid> | |
1027 | </biblioentry> | |
1028 | ||
1029 | <biblioentry> | |
1030 | <title> | |
1031 | IntelĀ® Compilers for Linux* -Compatibility with the GNU Compilers | |
1032 | </title> | |
1033 | ||
1034 | <biblioid> | |
1035 | <ulink url="http://developer.intel.com/software/products/compilers/techtopics/LinuxCompilersCompatibility.htm"> | |
1036 | </ulink> | |
1037 | </biblioid> | |
1038 | </biblioentry> | |
1039 | ||
1040 | <biblioentry> | |
1041 | <title> | |
1042 | Sun Solaris 2.9 : Linker and Libraries Guide (document 816-1386) | |
1043 | </title> | |
1044 | ||
1045 | <biblioid> | |
1046 | <ulink url="http://docs.sun.com/?p=/doc/816-1386&a=load"> | |
1047 | </ulink> | |
1048 | </biblioid> | |
1049 | </biblioentry> | |
1050 | ||
1051 | ||
1052 | <biblioentry> | |
1053 | <title> | |
1054 | Sun Solaris 2.9 : C++ Migration Guide (document 816-2459) | |
1055 | </title> | |
1056 | ||
1057 | <biblioid> | |
1058 | <ulink url="http://docs.sun.com/db/prod/solaris.9"> | |
1059 | </ulink> | |
1060 | </biblioid> | |
1061 | </biblioentry> | |
1062 | ||
1063 | <biblioentry> | |
1064 | <title> | |
1065 | ELF Symbol Versioning | |
1066 | </title> | |
1067 | ||
1068 | <author> | |
1069 | <firstname>Ulrich</firstname> | |
1070 | <surname>Drepper</surname> | |
1071 | </author> | |
1072 | ||
1073 | <biblioid> | |
1074 | <ulink url="http://people.redhat.com/drepper/symbol-versioning"> | |
1075 | </ulink> | |
1076 | </biblioid> | |
1077 | </biblioentry> | |
1078 | ||
1079 | <biblioentry> | |
1080 | <title> | |
1081 | C++ ABI for the ARM Architecture | |
1082 | </title> | |
1083 | ||
1084 | <biblioid> | |
1085 | <ulink url="http://www.arm.com/miscPDFs/8033.pdf"> | |
1086 | </ulink> | |
1087 | </biblioid> | |
1088 | </biblioentry> | |
1089 | ||
1090 | <biblioentry> | |
1091 | <title> | |
1092 | Dynamic Shared Objects: Survey and Issues | |
1093 | </title> | |
1094 | <subtitle> | |
1095 | ISO C++ J16/06-0046 | |
1096 | </subtitle> | |
1097 | ||
1098 | <author> | |
1099 | <firstname>Benjamin</firstname> | |
1100 | <surname>Kosnik</surname> | |
1101 | </author> | |
1102 | ||
1103 | <biblioid> | |
1104 | <ulink url="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1976.html"> | |
1105 | </ulink> | |
1106 | </biblioid> | |
1107 | </biblioentry> | |
1108 | ||
1109 | <biblioentry> | |
1110 | <title> | |
1111 | Versioning With Namespaces | |
1112 | </title> | |
1113 | <subtitle> | |
1114 | ISO C++ J16/06-0083 | |
1115 | </subtitle> | |
1116 | ||
1117 | <author> | |
1118 | <firstname>Benjamin</firstname> | |
1119 | <surname>Kosnik</surname> | |
1120 | </author> | |
1121 | ||
1122 | <biblioid> | |
1123 | <ulink url="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2013.html"> | |
1124 | </ulink> | |
1125 | </biblioid> | |
1126 | </biblioentry> | |
1127 | ||
1128 | </bibliography> | |
1129 | ||
4394b61e | 1130 | </sect1> |