]>
Commit | Line | Data |
---|---|---|
5408ce78 JM |
1 | \input texinfo.tex @c -*-texinfo-*- |
2 | @c %**start of header | |
3 | @setfilename g++FAQ.info | |
4 | @settitle Frequently asked questions about the GNU C++ compiler | |
5 | @setchapternewpage off | |
6 | @c version: @(#)g++FAQ.texi 1.56 09/15/97 | |
7 | @c %**end of header | |
8 | ||
9 | @iftex | |
10 | @finalout | |
11 | @end iftex | |
12 | @titlepage | |
13 | @title G++ FAQ | |
14 | @subtitle Frequently asked questions about the GNU C++ compiler | |
15 | @subtitle September 14, 1997 | |
16 | @sp 1 | |
17 | @author Joe Buck | |
18 | @page | |
19 | @end titlepage | |
20 | ||
21 | @ifinfo | |
22 | @node Top, basics, (dir), (dir) | |
23 | @top | |
24 | @unnumbered FAQ for g++ and libg++, by Joe Buck (jbuck@@synopsys.com) | |
25 | @end ifinfo | |
26 | ||
27 | @cindex FAQ for g++, latest version | |
28 | @cindex Archive site for FAQ lists | |
29 | @cindex rtfm.mit.edu | |
30 | @cindex Joe Buck <jbuck@@synopsys.com> | |
31 | @cindex FAQ for C++ | |
32 | ||
33 | This is a list of frequently asked questions (FAQ) for g++ users; thanks to | |
34 | all those who sent suggestions for improvements. Thanks to Marcus Speh | |
35 | for doing the index. A hypertext version is available on the World Wide | |
36 | Web at @file{http://www.cygnus.com/misc/g++FAQ_toc.html}. | |
37 | ||
38 | This document has just been reorganized a bit. There is some new | |
39 | information about upcoming g++ releases and egcs; more needs to be done | |
40 | but that will need to wait for next time. A diff would look misleadingly | |
41 | large, since I blew away and rebuilt the texinfo menus. | |
42 | ||
43 | Please send updates and corrections to the FAQ to | |
44 | @code{jbuck@@synopsys.com}. Please do @emph{not} use me as a resource | |
45 | to get your questions answered; that's what @file{gnu.g++.help} is for and I | |
46 | don't have the time to support the net's use of g++. | |
47 | ||
48 | Many FAQs, including this one, are available on the archive site | |
49 | ``rtfm.mit.edu''; see @* | |
50 | @file{ftp://rtfm.mit.edu/pub/usenet/news.answers}. | |
51 | This FAQ may be found in the subdirectory g++-FAQ. | |
52 | ||
53 | @cindex Marshall Cline | |
54 | @cindex comp.lang.c++ | |
55 | @cindex C++ FAQ | |
56 | This FAQ is intended to supplement, not replace, Marshall Cline's | |
57 | excellent FAQ for the C++ language and for the newsgroup | |
58 | @file{comp.lang.c++}. Especially if g++ is the first C++ | |
59 | compiler you've ever used, the question ``How do I do <X> with g++?'' | |
60 | is probably really ``How do I do <X> in C++?''. | |
61 | You can find this FAQ at | |
62 | @file{ftp://rtfm.mit.edu/pub/usenet/comp.lang.c++}, | |
63 | or in HTML form at @file{http://www.cerfnet.com/~mpcline/On-Line-C++-FAQs/}. | |
64 | ||
65 | @menu | |
66 | * basics:: What is g++? How do I get it? | |
67 | * installation:: How to install, installation problems | |
68 | * evolution:: The Evolution of g++ | |
69 | * User Problems:: Commonly reported problems and bugs | |
70 | * legalities:: Lawyer stuff, GPL, LGPL, etc. | |
71 | * index:: Index of terms | |
72 | ||
73 | --- The Detailed Node Listing --- | |
74 | ||
75 | The basics: what is g++? | |
76 | ||
77 | * latest versions:: | |
78 | * g++ for Unix:: | |
79 | * g++ for HP:: | |
80 | * g++ for Solaris 2.x:: | |
81 | * g++ for other platforms:: | |
82 | * 1.x vs 2.x versions:: | |
83 | ||
84 | Installation Issues and Problems | |
85 | ||
86 | * gcc-2 + g++-1:: | |
87 | * what else do I need?:: | |
88 | * use GNU linker?:: | |
89 | * Use GNU assembler?:: | |
90 | * shared libraries:: | |
91 | * repository:: | |
92 | * repo bugs:: | |
93 | * Use GNU C library?:: | |
94 | * Global constructor problems:: | |
95 | * Strange assembler errors:: | |
96 | * Other problems building libg++:: | |
97 | * More size_t problems:: | |
98 | * Rebuild libg++?:: | |
99 | * co-existing versions:: | |
100 | * Installing on Linux:: | |
101 | * Linux Slackware 3.0:: | |
102 | ||
103 | The Evolution of g++ | |
104 | ||
105 | * version 2.7.x:: | |
106 | * libstdc++:: | |
107 | * new work:: | |
108 | * egcs:: | |
109 | * When?:: | |
110 | ||
111 | User Problems | |
112 | ||
113 | * missing virtual table:: | |
114 | * for scope:: | |
115 | * const constructor:: | |
116 | * unused parameter warnings:: | |
117 | * jump crosses initialization:: | |
118 | * Demangler:: | |
119 | * static data members:: | |
120 | * internal compiler error:: | |
121 | * bug reports:: | |
122 | * porting to g++:: | |
123 | * name mangling:: | |
124 | * problems linking with other libraries:: | |
125 | * documentation:: | |
126 | * templates:: | |
127 | * undefined templates:: | |
128 | * redundant templates:: | |
129 | * Standard Template Library:: | |
130 | * STL and string:: | |
131 | * exceptions:: | |
132 | * namespaces:: | |
133 | * agreement with standards:: | |
134 | * compiling standard libraries:: | |
135 | * debugging on SVR4 systems:: | |
136 | * debugging problems on Solaris:: | |
137 | * X11 conflicts with libg++:: | |
138 | * assignment to streams:: | |
139 | @end menu | |
140 | ||
141 | @node basics, installation, Top, Top | |
142 | @chapter The basics: what is g++? | |
143 | ||
144 | @cindex Free Software Foundation | |
145 | @cindex GNU Public License | |
146 | @cindex GPL | |
147 | ||
148 | g++ is the traditional nickname of GNU C++, a freely redistributable | |
149 | C++ compiler produced by the Free Software Foundation plus dozens of | |
150 | skilled volunteers. I say ``traditional nickname'' because the GNU | |
151 | compiler suite, gcc, bundles together compilers for C, Objective-C, | |
152 | and C++ in one package. | |
153 | ||
154 | While the source code to gcc/g++ can be downloaded for free, | |
155 | it is not public domain, but is protected by the GNU Public License, | |
156 | or GPL (@pxref{legalities}). | |
157 | ||
158 | @menu | |
159 | * latest versions:: | |
160 | * g++ for Unix:: | |
161 | * g++ for HP:: | |
162 | * g++ for Solaris 2.x:: | |
163 | * g++ for other platforms:: | |
164 | * 1.x vs 2.x versions:: | |
165 | @end menu | |
166 | ||
167 | @node latest versions, g++ for Unix, basics, basics | |
168 | @section What is the latest version of gcc, g++, and libg++? | |
169 | ||
170 | @cindex gcc/g++, version date | |
171 | The current version of gcc/g++ is 2.7.2.3, released August 20, 1997. | |
172 | Although that looks very recent, the only change is a minor patch to | |
173 | resolve a problem with Linux and the GNU C library; users not interested | |
174 | in that functionality have no reason to upgrade. | |
175 | ||
176 | The current version of libg++ is 2.7.2, released July 4, 1996. | |
177 | The last release of gcc/g++ with improvements to the C++ front end was | |
178 | 2.7.2, released Nov. 25, 1995, nearly two years ago. | |
179 | ||
180 | I would strongly recommend that anyone using a g++ version earlier | |
181 | than 2.7.2 should upgrade if at all possible (@pxref{version 2.7.x}). | |
182 | ||
183 | For some non-Unix platforms, the latest port of gcc may be an earlier | |
184 | version (2.6.3, say). You'll need to use a version of libg++ that | |
185 | has the same first two digits as the compiler version, e.g. use libg++ | |
186 | 2.6.x (for the latest x you can find) with gcc version 2.6.3. | |
187 | ||
188 | The latest "1.x" version of gcc is 1.42, and the latest "1.x" version of | |
189 | g++ is 1.42.0. | |
190 | While gcc 1.42 is quite usable for C programs, | |
191 | I recommend against using g++ 1.x except in special circumstances | |
192 | (and I can't think of any such circumstances). | |
193 | ||
194 | @node g++ for Unix, g++ for HP, latest versions, basics | |
195 | @section How do I get a copy of g++ for Unix? | |
196 | ||
197 | First, you may already have it if you have gcc for your platform; | |
198 | g++ and gcc are combined now (as of gcc version 2.0). | |
199 | @cindex GNU gcc, version | |
200 | @cindex GNU g++ and gcc | |
201 | ||
202 | You can get g++ from a friend who has a copy, by anonymous FTP or | |
203 | UUCP, or by ordering a tape or CD-ROM from the Free Software | |
204 | Foundation. | |
205 | @cindex g++, ordering | |
206 | @cindex g++, getting a copy | |
207 | ||
208 | The Free Software Foundation is a nonprofit organization that | |
209 | distributes software and manuals to raise funds for more GNU | |
210 | development. Getting your copy from the FSF contributes directly to | |
211 | paying staff to develop GNU software. CD-ROMs cost $400 if an | |
212 | organization is buying, or $100 if an individual is buying. Tapes | |
213 | cost around $200 depending on media type. I recommend asking for | |
214 | version 2, not version 1, of g++. | |
215 | @cindex FSF [Free Software Foundation] | |
216 | @cindex GNU [GNU's not unix] | |
217 | ||
218 | For more information about ordering from the FSF, contact | |
219 | gnu@@prep.ai.mit.edu, phone (617) 542-5942 or anonymous ftp file | |
220 | @file{ftp://prep.ai.mit.edu/pub/gnu/GNUinfo/ORDERS} (you can | |
221 | also use one of the sites listed below if you can't get into ``prep''). | |
222 | ||
223 | @cindex FSF, contact <gnu@@prep.ai.mit.edu> | |
224 | ||
225 | Here is a list of anonymous FTP archive sites for GNU software. | |
226 | If no directory is given, look in @file{/pub/gnu}. | |
227 | ||
228 | @cindex GNUware, anonymous FTP sites | |
229 | ||
230 | @example | |
231 | ASIA: ftp.cs.titech.ac.jp, tron.um.u-tokyo.ac.jp:/pub/GNU/prep | |
232 | cair-archive.kaist.ac.kr, ftp.nectec.or.th:/pub/mirrors/gnu | |
233 | ||
234 | AUSTRALIA: archie.au:/gnu (archie.oz or archie.oz.au for ACSnet) | |
235 | ||
236 | AFRICA: ftp.sun.ac.za | |
237 | ||
238 | MIDDLE-EAST: ftp.technion.ac.il:/pub/unsupported/gnu | |
239 | ||
240 | EUROPE: irisa.irisa.fr, ftp.univ-lyon1.fr, | |
241 | ftp.mcc.ac.uk, unix.hensa.ac.uk:/mirrors/uunet/systems/gnu, | |
242 | src.doc.ic.ac.uk:/gnu, ftp.ieunet.ie, ftp.eunet.ch, | |
243 | nic.switch.ch:/mirror/gnu, ftp.informatik.rwth-aachen.de, | |
244 | ftp.informatik.tu-muenchen.de, ftp.win.tue.nl, ftp.nl.net, | |
245 | ftp.etsimo.uniovi.es, ftp.funet.fi, ftp.denet.dk, | |
246 | ftp.stacken.kth.se, isy.liu.se, ftp.luth.se:/pub/unix/gnu, | |
247 | ftp.sunet.se, archive.eu.net | |
248 | ||
249 | SOUTH AMERICA: ftp.inf.utfsm.cl, ftp.unicamp.br | |
250 | ||
251 | WESTERN CANADA: ftp.cs.ubc.ca:/mirror2/gnu | |
252 | ||
253 | USA: wuarchive.wustl.edu:/systems/gnu, labrea.stanford.edu, | |
254 | ftp.digex.net, ftp.kpc.com:/pub/mirror/gnu, f.ms.uky.edu:/pub3/gnu, | |
255 | jaguar.utah.edu:/gnustuff, ftp.hawaii.edu:/mirrors/gnu, | |
256 | uiarchive.cso.uiuc.edu, ftp.cs.columbia.edu:/archives/gnu/prep, | |
257 | gatekeeper.dec.com:/pub/GNU, ftp.uu.net:/systems/gnu | |
258 | @end example | |
259 | ||
260 | The ``official site'' is prep.ai.mit.edu, but your transfer will probably | |
261 | go faster if you use one of the above machines. | |
262 | ||
263 | @cindex gzip | |
264 | Most GNU utilities are compressed with ``gzip'', the GNU compression | |
265 | utility. All GNU archive sites should have a copy of this program, | |
266 | which you will need to uncompress the distributions. | |
267 | ||
268 | @cindex libg++ | |
269 | Don't forget to retrieve libg++ as well! | |
270 | ||
271 | @node g++ for HP, g++ for Solaris 2.x, g++ for Unix, basics | |
272 | @section Getting gcc/g++ for the HP Precision Architecture | |
273 | ||
274 | @cindex HP Precision Architecture | |
275 | @cindex Hewlett-Packard | |
276 | @cindex GNU GAS | |
277 | @cindex GNU gdb | |
278 | ||
279 | If you use the HP Precision Architecture (HP-9000/7xx and HP-9000/8xx) | |
280 | and you want to use debugging, you'll need to use the GNU assembler, GAS | |
281 | (version 2.3 or later). If you build from source, you must tell the | |
282 | configure program that you are using GAS or you won't get debugging | |
283 | support. A non-standard debug format is used, since until recently HP | |
284 | considered their debug format a trade secret. Thanks to the work of | |
285 | lots of good folks both inside and outside HP, the company has seen the | |
286 | error of its ways and has now released the required information. The | |
287 | team at the University of Utah that did the gcc port now has code that | |
288 | understands the native HP format. | |
289 | ||
290 | There are binaries for GNU tools in | |
291 | @file{ftp://jaguar.cs.utah.edu/dist/}, | |
292 | but these are older versions. | |
293 | ||
294 | Jeff Law has left the University of Utah, so the Utah prebuilt | |
295 | binaries may be discontinued. | |
296 | ||
297 | @node g++ for Solaris 2.x, g++ for other platforms, g++ for HP, basics | |
298 | @section Getting gcc/g++ binaries for Solaris 2.x | |
299 | ||
300 | ``Sun took the C compiler out of Solaris 2.x. Am I stuck?'' | |
301 | ||
302 | @cindex Solaris | |
303 | @cindex gcc/g++ binaries for Solaris | |
304 | ||
305 | You'll need to get prebuilt binaries from someone. | |
306 | ||
307 | It used to be that you could get GCC binaries from prep.ai.mit.edu; | |
308 | these are no longer there. | |
309 | ||
310 | @cindex Solaris pkgadd utility | |
311 | The WWW site @file{http://smc.vnet.net/solaris_2.5.html} | |
312 | contains various | |
313 | GNU and freeware programs for Solaris2.5 running on the sparc. These are | |
314 | packaged to enable easy installation using the Solaris ``pkgadd'' utility. | |
315 | These include GNU emacs, gcc, gdb, perl, and others. These versions | |
316 | are more recent than the binaries at ``prep'' (gcc 2.7.2 and libg++ | |
317 | 2.7.1 are there). | |
318 | ||
319 | @node g++ for other platforms, 1.x vs 2.x versions, g++ for Solaris 2.x, basics | |
320 | @section How do I get a copy of g++ for (some other platform)? | |
321 | ||
322 | @cindex Windows NT support | |
323 | As of gcc-2.7.x, there is Windows NT support in gcc. Some special | |
324 | utilities are required. See the INSTALL file from the distribution. | |
325 | If you're interested in GNU tools on Windows NT, see | |
326 | @file{http://www.cygnus.com/misc/gnu-win32/} on the WWW, or the | |
327 | anonymous FTP directory | |
328 | @file{ftp://ftp.cygnus.com/pub/gnu-win32/}. | |
329 | ||
330 | @cindex VMS support | |
331 | @cindex VAX | |
332 | @cindex VMS, g++/libg++ precompiled | |
333 | ||
334 | The standard gcc/g++ distribution includes VMS support for the Vax. | |
335 | Since the FSF people don't use VMS, it's likely to be somewhat less | |
336 | solid than the Unix version. Precompiled copies of g++ and libg++ in | |
337 | VMS-installable form for the Vax are available by FTP from | |
338 | @file{ftp://mango.rsmas.miami.edu/pub/VMS-gcc/}. | |
339 | ||
340 | @cindex OpenVMS/Alpha | |
341 | Klaus Kaempf (kkaempf@@progis.de) | |
342 | has done a port to OpenVMS for the Alpha; this is not yet a | |
343 | part of the official gcc/g++. | |
344 | The port includes g++ and all libraries from the libg++ distribution. See | |
345 | @file{http://www.progis.de} for more details. | |
346 | ||
347 | @cindex MS-DOS support | |
348 | @cindex Delorie's gcc/g++ | |
349 | @cindex DJGPP | |
350 | @cindex EMX | |
351 | There are two different versions of gcc/g++ for MS-DOS: EMX and DJGPP. | |
352 | EMX also works for OS/2 and is described later. | |
353 | DJGPP is DJ Delorie's port. It can be found on many FTP archive | |
354 | sites; try | |
355 | @file{ftp://ftp.coast.net/SimTel/vendors/djgpp/} | |
356 | or, for a complete list, see | |
357 | @file{http://www.delorie.com/djgpp/getting.html}. | |
358 | ||
359 | ||
360 | The latest version of DJGPP is 2.00. See | |
361 | @file{http://www.delorie.com/djgpp/v2/} for information on this version. | |
362 | ||
363 | FSF sells floppies with DJGPP on them; see above for ordering software | |
364 | from the FSF. | |
365 | ||
366 | DJGPP has its own newsgroup: @file{comp.os.msdos.djgpp}. | |
367 | ||
368 | @cindex Amiga support | |
369 | Development and porting efforts for GNU tools, including gcc/g++, for | |
370 | the Amiga are maintained by an initiative named ADE (Amiga Developers | |
371 | Environment. More information about ADE is available at | |
372 | @file{http://www.ninemoons.com/}. | |
373 | ||
374 | For more information on Amiga ports of gcc/g++, retrieve the file | |
375 | @file{ftp://prep.ai.mit.edu/pub/gnu/MicrosPorts/Amiga}. | |
376 | ||
377 | @cindex Atari ST support | |
378 | A port of gcc to the Atari ST can be found at @* | |
379 | @file{ftp://atari.archive.umich.edu/atari/Gnustuff/Tos} | |
380 | along with many | |
381 | other GNU programs. This version is usually the same as the latest FSF | |
382 | release. See the ``Software FAQ'' for the Usenet group | |
383 | @file{comp.sys.atari.st} for more information. | |
384 | ||
385 | @cindex EMX port | |
386 | @cindex OS/2 support | |
387 | ||
388 | EMX is a port of gcc to OS/2; it can also be used on MS-DOS. In addition to | |
389 | the compiler port, the EMX port's C library attempts to provide a | |
390 | Unix-like environment. For more information ask around on | |
391 | @file{comp.os.os2.programmer.porting}. Version 0.9c, based on gcc-2.7.2.1, | |
392 | was released in | |
393 | November 1996. It is available by FTP and the WWW from, among other | |
394 | places | |
395 | ||
396 | @example | |
397 | @file{http://www.os2ss.com/unix/emx09c/} | |
398 | @file{ftp://ftp.cdrom.com/pub/os2/emx09c/} (US) | |
399 | @file{ftp://ftp.leo.org/pub/comp/os/os2/leo/devtools/emx+gcc/} (Germany) | |
400 | @end example | |
401 | ||
402 | Eberhard Mattes did the EMX port. His address is | |
403 | mattes@@azu.informatik.uni-stuttgart.de. | |
956d6950 | 404 | Read the FAQ file included with the distribution before harassing the author. |
5408ce78 JM |
405 | |
406 | @cindex Apple support | |
407 | @cindex Macintosh support | |
408 | ||
409 | I'm looking for more information on gcc/g++ support on the Apple | |
410 | Macintosh. Until recently, this FAQ did not provide such information, | |
411 | but FSF is no longer boycotting Apple as the League for Programming | |
412 | Freedom boycott has been dropped. | |
413 | ||
414 | Versions 1.37.1 and 2.3.3 of gcc were ported by Stan Shebs and are available | |
415 | at @* | |
416 | @file{ftp://ftp.cygnus.com/pub/mac} | |
417 | ||
418 | They are both interfaced to MPW. | |
419 | Stan is working on a version using the current (post-2.7) sources, contact | |
420 | him directly (shebs@@cygnus.com) for more information. | |
421 | ||
422 | @node 1.x vs 2.x versions, , g++ for other platforms, basics | |
423 | @section But I can only find g++-1.42! | |
424 | ||
425 | ``I keep hearing people talking about g++ 2.7.2 (or some other number | |
426 | starting with 2), but the latest version I can find is g++ 1.42. | |
427 | Where is it?'' | |
428 | ||
429 | @cindex Objective-C | |
430 | @cindex g++, version number | |
431 | As of gcc 2.0, C, C++, and Objective-C as well are all combined into a | |
432 | single distribution called gcc. If you get gcc you already have g++. The | |
433 | standard installation procedure for any gcc version 2 compiler will | |
434 | install the C++ compiler as well. | |
435 | ||
436 | One could argue that we shouldn't even refer to "g++-2.x.y" but it's a | |
437 | convention. It means ``the C++ compiler included with gcc-2.x.y.'' | |
438 | ||
439 | @node installation, evolution, basics, Top | |
440 | @chapter Installation Issues and Problems | |
441 | ||
442 | @menu | |
443 | * gcc-2 + g++-1:: | |
444 | * what else do I need?:: | |
445 | * use GNU linker?:: | |
446 | * Use GNU assembler?:: | |
447 | * shared libraries:: | |
448 | * repository:: | |
449 | * repo bugs:: | |
450 | * Use GNU C library?:: | |
451 | * Global constructor problems:: | |
452 | * Strange assembler errors:: | |
453 | * Other problems building libg++:: | |
454 | * More size_t problems:: | |
455 | * Rebuild libg++?:: | |
456 | * co-existing versions:: | |
457 | * Installing on Linux:: | |
458 | * Linux Slackware 3.0:: | |
459 | @end menu | |
460 | ||
461 | @node gcc-2 + g++-1, what else do I need?, installation, installation | |
462 | @section I can't build g++ 1.x.y with gcc-2.x.y! | |
463 | ||
464 | ``I obtained gcc-2.x.y and g++ 1.x.y and I'm trying to build it, but | |
465 | I'm having major problems. What's going on?'' | |
466 | ||
467 | @cindex g++, building | |
468 | If you wish to build g++-1.42, you must obtain gcc-1.42 first. The | |
469 | installation instructions for g++ version 1 leave a lot to be desired, | |
470 | unfortunately, and I would recommend that, unless you have a special | |
471 | reason for needing the 1.x compiler, that C++ users use the latest | |
472 | g++-2.x version, as it | |
473 | is the version that is being actively maintained. | |
474 | ||
475 | @cindex g++, template support | |
476 | @cindex Templates | |
477 | @cindex ANSI draft standard | |
478 | There is no template support in g++-1.x, and it is generally much further | |
479 | away from the ANSI draft standard than g++-2.x is. | |
480 | ||
481 | @node what else do I need?, use GNU linker?, gcc-2 + g++-1, installation | |
482 | @section OK, I've obtained gcc; what else do I need? | |
483 | ||
484 | @cindex libg++ | |
485 | First off, you'll want libg++ as you can do almost nothing without it | |
486 | (unless you replace it with some other class library). | |
487 | ||
488 | @cindex GNU GAS | |
489 | @cindex GNU GAS [assembler] | |
490 | Second, depending on your platform, you may need "GAS", the GNU assembler, | |
491 | or the GNU linker (see next question). | |
492 | ||
493 | @cindex GNU gdb | |
494 | Finally, while it is not required, you'll almost certainly want the GNU | |
495 | debugger, gdb. The latest version is | |
496 | 4.16, released April 22, 1996. | |
497 | Other debuggers (like dbx, for example) will normally not be able to | |
498 | understand at least some of the debug information produced by g++. | |
499 | ||
500 | @node use GNU linker?, Use GNU assembler?, what else do I need?, installation | |
501 | @section Should I use the GNU linker, or should I use "collect"? | |
502 | ||
503 | @cindex Linker | |
504 | @cindex System VR3, linker | |
505 | @cindex System VR4, linker | |
506 | First off, for novices: special measures must be taken with C++ to arrange | |
507 | for the calling of constructors for global or static objects before the | |
508 | execution of your program, and for the calling of destructors at the end. | |
509 | (Exception: System VR3 and System VR4 linkers, Linux/ELF, and some other | |
510 | systems support user-defined | |
511 | segments; g++ on these systems requires neither the GNU linker nor | |
512 | collect. So if you have such a system, the answer is that you don't | |
513 | need either one, though using GNU ld does have some advantages over | |
514 | the native linker in some cases). | |
515 | ||
516 | @cindex AT&T cfront | |
517 | @cindex Cfront-end | |
518 | @cindex collect program | |
519 | @cindex GNU linker | |
520 | @cindex GNU binutils | |
521 | If you have experience with AT&T's "cfront", this function is performed | |
522 | there by programs named "patch" or "munch". With GNU C++, it is performed | |
523 | either by the GNU linker or by a program known as "collect". The collect | |
524 | program is part of the gcc-2.x distribution; you can obtain the GNU linker | |
525 | separately as part of the "binutils" package. The latest version of | |
526 | binutils is 2.7, released July 10, 1996; 2.6 is in common use and works | |
527 | well. | |
528 | ||
529 | (To be technical, it's "collect2"; there were originally several | |
530 | alternative versions of collect, and this is the one that survived). | |
531 | ||
532 | There are advantages and disadvantages to either choice. | |
533 | ||
534 | Advantages of the GNU linker: | |
535 | @cindex GNU linker, advantages | |
536 | @cindex GNU ld | |
537 | @cindex ld [GNU linker] | |
538 | ||
539 | It's faster than using collect -- collect basically runs the standard Unix | |
540 | linker on your program twice, inserting some extra code after the first | |
541 | pass to call the constructors. This is a sizable time penalty for large | |
542 | programs. The GNU linker does not require this extra pass. | |
543 | ||
544 | GNU ld reports undefined symbols using their true names, not the mangled | |
545 | names (but as of 2.7.0 so does collect). | |
546 | ||
547 | If there are undefined symbols, GNU ld reports which object file(s) refer to | |
548 | the undefined symbol(s). On some OSes (e.g. SunOS, Solaris) the native | |
549 | linker does not do this, so you have to track down who's referring to | |
550 | the missing symbols yourself. | |
551 | ||
552 | As of binutils version 2.2, on systems that use the so-called "a.out" | |
553 | debug format (e.g. Suns running SunOS 4.x), the GNU linker compresses | |
554 | the debug symbol table considerably. The 2.7 version adds some symbol | |
555 | table compression for ELF and Solaris targets. | |
556 | ||
557 | @cindex collect linker, advantages | |
558 | Advantages of collect: | |
559 | ||
560 | @cindex Shared libraries | |
561 | If your native linker supports shared libraries, you can use shared | |
562 | libraries with collect. This used to be a strong reason @emph{not} | |
563 | to use the GNU linker, but recent versions of GNU ld support linking | |
564 | with shared libraries on many platforms, and creating shared libraries | |
565 | on a few (such as Intel x86 systems that use ELF object format as well | |
566 | as SunOS and Solaris). | |
567 | ||
568 | @xref{shared libraries} | |
569 | ||
570 | @cindex GNU linker, porting | |
571 | The GNU linker has not been ported to as many platforms as g++ has, so you | |
572 | may be forced to use collect. | |
573 | ||
574 | If you use collect, you don't need to get something extra and figure out | |
575 | how to install it; the standard gcc installation procedure will do it for you. | |
576 | ||
577 | I used to say at this point that I don't see a clear win for either | |
578 | linking alternative, but with all the improvements in the GNU linker | |
579 | I think that it is now the better choice. Take your pick. | |
580 | ||
581 | If you run Linux, the only available linker is the GNU linker. | |
582 | ||
583 | @node Use GNU assembler?, shared libraries, use GNU linker?, installation | |
584 | @section Should I use the GNU assembler, or my vendor's assembler? | |
585 | ||
586 | @cindex Assembler | |
587 | @cindex GNU GAS | |
588 | This depends on your platform and your decision about the GNU linker. For | |
589 | most platforms, you'll need to use GAS if you use the GNU linker. For | |
590 | some platforms, you have no choice; check the gcc installation notes to | |
591 | see whether you must use GAS. But you can usually use the vendor's | |
592 | assembler if you don't use the GNU linker. | |
593 | ||
594 | The GNU assembler assembles faster than many native assemblers; however, | |
595 | on many platforms it cannot support the local debugging format. | |
596 | ||
597 | It used to be that the GNU assembler couldn't handle | |
598 | position-independent code on SunOS. This is no longer true if you | |
599 | have version 2.6 or newer. | |
600 | ||
601 | On HPUX or IRIX, you must use GAS (and configure gcc with the | |
602 | @code{--with-gnu-as} option) to debug your programs. GAS is | |
603 | strongly recommended particularly on the HP platform because of | |
604 | limitations in the HP assembler. | |
605 | ||
606 | The GNU assembler has been merged with the binutils | |
607 | distribution, so the GNU assembler and linker are now together in | |
608 | this package (as of binutils version 2.5.1). | |
609 | ||
610 | On Linux the assembler is the GNU assembler. | |
611 | ||
612 | @node shared libraries, repository, Use GNU assembler?, installation | |
613 | @section How do I build shared libraries with g++? | |
614 | ||
615 | For gcc-2.7.0 and later, building C++ shared libraries should work fine | |
616 | on supported platforms (HPUX 9+, IRIX 5+, DEC UNIX (formerly OSF/1), | |
617 | SGI/IRIX, AIX, SunOS 4, Linux/ELF and all targets using SVR4-style ELF shared | |
618 | libraries). There are two separate issues: building libg++ as a shared | |
619 | library, and making your own shared libraries. For libg++ it is simply | |
620 | a matter of giving the @code{--enable-shared} option to the configure | |
621 | program. When compiling your own code for shared libraries you | |
622 | generally | |
623 | must use the @code{-fPIC} flag to get position-independent code. | |
624 | ||
625 | @cindex -shared flag of gcc | |
626 | ||
627 | If your shared library contains global or static objects with | |
628 | constructors, then make sure to use @code{gcc -shared}, not | |
629 | @code{ld}, to create the shared library. This will make sure | |
630 | that any processor-specific magic needed to execute the constructors | |
631 | is included. | |
632 | ||
633 | In theory, constructors for objects in your shared library should be | |
634 | called when the library is opened (by dlopen or equivalent). This | |
635 | does not work on some platforms (e.g. SunOS4; it does work on Solaris | |
636 | and ELF systems such as Linux): on the broken platforms, the | |
637 | constructors are not called correctly. | |
638 | ||
639 | David Nilsen has suggested the following workaround: | |
640 | ||
641 | The thing to realize is that if you link your dynamic module with the | |
642 | @code{-shared} flag, the collect program nicely groups all the static | |
643 | ctors/dtors for you into a list and sets up a function that will call | |
644 | them (Note: this means that this trick won't work if you use the GNU | |
645 | linker without collect (@pxref{use GNU linker?}). | |
646 | ||
647 | The magic is knowing these function names. Currently, they're called: | |
648 | ||
649 | @example | |
650 | _GLOBAL__DI <-- calls all module constructors | |
651 | _GLOBAL__DD <-- calls all module destructors | |
652 | @end example | |
653 | ||
654 | [ possibly the leading underscore will differ between platforms: jbuck ] | |
655 | ||
656 | Therefore, if you make a wrapper around dlopen that looks up the | |
657 | symbol @code{_GLOBAL__DI} (or @code{__GLOBAL__DI} on SunOS4 machines), and | |
658 | calls it, you'll simulate getting the constructors called. | |
659 | ||
660 | You also need to set up the destructors to be called as well, so you | |
661 | need to put a wrapper around dlclose, which will call the | |
662 | @code{_GLOBAL__DD} function in the module when/if it's unloaded. | |
663 | ||
664 | Lastly, to get things 100% correct, you need to set up the destructors | |
665 | to also be called if the module is not unloaded, but the main program | |
666 | exits. I do this by registering a single function with @code{atexit()} that | |
667 | calls all the destructors left in dynamically loaded modules. | |
668 | ||
669 | @cindex Shared version of libg++ | |
670 | Check the file @file{README.SHLIB} from the libg++ distribution for more | |
671 | about making and using shared libraries. | |
672 | ||
673 | @cindex Shared libraries with HP | |
674 | ||
675 | A patch is needed to build shared versions of version 2.7.2 of libg++ | |
676 | and libstdc++ on the HP-PA architecture. You can find the patch at | |
677 | @file{ftp://ftp.cygnus.com/pub/g++/libg++-2.7.2-hppa-gcc-fix}. | |
678 | ||
679 | @node repository, repo bugs, shared libraries, installation | |
680 | @section How do I use the new repository code? | |
681 | ||
682 | @cindex repo patch | |
683 | Because there is some disagreement about the details of the template | |
684 | repository mechanism, you'll need to obtain a patch from Cygnus Support | |
685 | to enable the 2.7.2 repository code. You can obtain the patch by | |
686 | anonymous FTP: @file{ftp://ftp.cygnus.com/pub/g++/gcc-2.7.2-repo.gz}. | |
687 | ||
688 | There are patches for 2.7.0 and 2.7.1 in the same directory, though | |
689 | if you're going to rebuild the compiler you should use the latest one. | |
690 | ||
691 | @cindex repo patch for BSD | |
692 | If you're running NetBSD or BSDI, the Cygnus repo patch is not quite | |
693 | correct. Tim Liddelow has made an alternate version available at | |
694 | @file{ftp://ftp.cst.com.au/pub/gcc-2.7.2-repo-bsd.gz}. | |
695 | ||
696 | After you've applied the patch, the @code{-frepo} flag will enable the | |
697 | repository mechanism. The flag works much like the existing | |
698 | @code{-fno-implicit-templates} flag, except that auxiliary files, with | |
699 | an @file{.rpo} extension, are built that specify what template | |
700 | expansions are needed. At link time, the (patched) collect program | |
701 | detects missing templates and recompiles some of the object files | |
702 | so that the required templates are expanded. | |
703 | ||
704 | Note that the mechanism differs from that of cfront in that template | |
705 | definitions still must be visible at the point where they are to be | |
706 | expanded. No assumption is made that @file{foo.C} contains template | |
707 | definitions corresponding to template declarations in @file{foo.h}. | |
708 | ||
709 | @cindex closure with repo | |
710 | @cindex template closure | |
711 | Jason Merrill writes: ``To perform closure on a set of objects, just try | |
712 | to link them together. It will fail, but as a side effect all needed | |
713 | instances will be generated in the objects.'' | |
714 | ||
715 | @node repo bugs, Use GNU C library?, repository, installation | |
716 | @section Known bugs and problems with the repo patch | |
717 | ||
718 | ``The @code{-frepo} won't expand templated friend functions!'' | |
719 | ||
720 | This is a known bug; currently you'll have to explicitly instantiate | |
721 | friend functions when using @code{-frepo} due to this bug (in 2.7.0 | |
722 | through 2.7.2 at least). | |
723 | ||
724 | With earlier versions of the repo patch, there was a bug that happens | |
725 | when you have given a quoted command line switch, something like | |
726 | ||
727 | @example | |
728 | -D'MESSAGE="hello there"' | |
729 | @end example | |
730 | ||
731 | The repo code tries to recompile files using the same flags you | |
732 | originally specified, but doesn't quote arguments that need quoting, | |
733 | resulting in failures in some cases. This is no longer a problem | |
734 | with the 2.7.2 patch. | |
735 | ||
736 | @node Use GNU C library?, Global constructor problems, repo bugs, installation | |
737 | @section Should I use the GNU C library? | |
738 | ||
739 | @cindex GNU C library | |
740 | @cindex libg++ | |
741 | At this point in time, no (unless you are running Linux or the GNU Hurd | |
742 | system). The GNU C library is still very young, and | |
743 | libg++ still conflicts with it in some places. Use your native C library | |
744 | unless you know a lot about the gory details of libg++ and gnu-libc. This | |
745 | will probably change in the future. | |
746 | ||
747 | @node Global constructor problems, Strange assembler errors, Use GNU C library?, installation | |
748 | @section Global constructors aren't being called | |
749 | ||
750 | @cindex global constructors | |
751 | ``I've installed gcc and it almost works, but constructors and | |
752 | destructors for global objects and objects at file scope aren't being | |
753 | called. What did I do wrong?'' | |
754 | ||
755 | @cindex collect program | |
756 | It appears that you are running on a platform that requires you to | |
757 | install either "collect2" or the GNU linker, and you have done neither. | |
758 | For more information, see the section discussing the GNU linker | |
759 | (@pxref{use GNU linker?}). | |
760 | ||
761 | @cindex constructor problems on Solaris | |
762 | @cindex Solaris, constructor problems | |
763 | On Solaris 2.x, you shouldn't need a collect program and GNU ld doesn't run. | |
764 | If your global constructors aren't being called, you may need to install | |
765 | a patch, available from Sun, to fix your linker. The number of the | |
766 | ``jumbo patch'' that applies is 101409-03. Thanks to Russell Street | |
767 | (r.street@@auckland.ac.nz) for this info. | |
768 | ||
769 | @cindex IRIX, installing collect | |
770 | It appears that on IRIX, the collect2 program is not being installed | |
771 | by default during the installation process, though it is required; | |
772 | you can install it manually by executing | |
773 | ||
774 | @example | |
775 | make install-collect2 | |
776 | @end example | |
777 | ||
778 | from the gcc source directory after installing the compiler. (I'm | |
779 | not certain for which versions of gcc this problem occurs, and whether | |
780 | it is still present). | |
781 | ||
782 | @node Strange assembler errors, Other problems building libg++, Global constructor problems, installation | |
783 | @section Strange assembler errors when linking C++ programs | |
784 | ||
785 | ``I've installed gcc and it seemed to go OK, but when I attempt to link | |
786 | any C++ program, I'm getting strange errors from the assembler! How | |
787 | can that be?'' | |
788 | ||
789 | The messages in question might look something like | |
790 | ||
791 | @example | |
792 | as: "/usr/tmp/cca14605.s", line 8: error: statement syntax | |
793 | as: "/usr/tmp/cca14605.s", line 14: error: statement syntax | |
794 | @end example | |
795 | ||
796 | (on a Sun, different on other platforms). The important thing is that | |
797 | the errors come out at the link step, @emph{not} when a C++ file is | |
798 | being compiled. | |
799 | ||
800 | @cindex nm program | |
801 | @cindex GNU nm program | |
802 | Here's what's going on: the collect2 program uses the Unix ``nm'' | |
803 | program to obtain a list of symbols for the global constructors and | |
804 | destructors, and it builds a little assembly language module that | |
805 | will permit them all to be called. If you're seeing this symptom, | |
806 | you have an old version of GNU nm somewhere on your path. This old | |
807 | version prints out symbol names in a format that the collect2 program | |
808 | does not expect, so bad assembly code is generated. | |
809 | ||
810 | The solution is either to remove the old version of GNU nm from your | |
811 | path (and that of everyone else who uses g++), or to install a newer | |
812 | version (it is part of the GNU "binutils" package). Recent versions | |
813 | of GNU nm do not have this problem. | |
814 | ||
815 | @node Other problems building libg++, More size_t problems, Strange assembler errors, installation | |
816 | @section Other problems building libg++ | |
817 | @cindex libg++ on Ultrix | |
818 | @cindex libg++ on SunOS | |
819 | ||
820 | ``I am having trouble building libg++. Help!'' | |
821 | ||
822 | On some platforms (for example, Ultrix), you may see errors complaining | |
823 | about being unable to open dummy.o. On other platforms (for example, | |
824 | SunOS), you may see problems having to do with the type of size_t. | |
825 | The fix for these problems is to make libg++ by saying "make CC=gcc". | |
826 | According to Per Bothner, it should no longer be necessary to specify | |
827 | "CC=gcc" for libg++-2.3.1 or later. | |
828 | ||
829 | ``I built and installed libg++, but g++ can't find it. Help!'' | |
830 | ||
831 | The string given to @file{configure} that identifies your system must | |
832 | be the same when you install libg++ as it was when you installed gcc. | |
833 | Also, if you used the @code{--prefix} option to install gcc somewhere | |
834 | other than @file{/usr/local}, you must use the same value for | |
835 | @code{--prefix} when installing libg++, or else g++ will not be able | |
836 | to find libg++. | |
837 | ||
838 | @cindex patch for libg++-2.6.2 | |
839 | ||
840 | The toplevel Makefile in the libg++ 2.6.2 distribution is broken, which | |
841 | along with a bug in g++ 2.6.3 causes problems linking programs that use the | |
842 | libstdc++ complex classes. A patch for this is available from | |
843 | @file{ftp://ftp.cygnus.com//pub/g++/libg++-2.6.2-fix.gz}. | |
844 | ||
845 | @node More size_t problems, Rebuild libg++?, Other problems building libg++, installation | |
846 | @section But I'm @emph{still} having problems with @code{size_t}! | |
847 | ||
848 | @cindex Type of size_t | |
849 | ``I did all that, and I'm @emph{still} having problems with disagreeing | |
850 | definitions of size_t, SIZE_TYPE, and the type of functions like | |
851 | @code{strlen}.'' | |
852 | ||
853 | @cindex _G_config.h | |
854 | The problem may be that you have an old version of @file{_G_config.h} | |
855 | lying around. As of libg++ version 2.4, @file{_G_config.h}, since it is | |
856 | platform-specific, is inserted into a different directory; most include | |
857 | files are in @file{$prefix/lib/g++-include}, but this file now lives in | |
858 | @file{$prefix/$arch/include}. If, after upgrading your libg++, you find that | |
859 | there is an old copy of @file{_G_config.h} left around, remove it, | |
860 | otherwise g++ will find the old one first. | |
861 | ||
862 | @node Rebuild libg++?, co-existing versions, More size_t problems, installation | |
863 | @section Do I need to rebuild libg++ to go with my new g++? | |
864 | ||
865 | ``After I upgraded g++ to the latest version, I'm seeing undefined | |
866 | symbols.'' | |
867 | ||
868 | or | |
869 | ||
870 | ``If I upgrade to a new version of g++, do I need to reinstall libg++?'' | |
871 | ||
872 | @cindex Incompatibilities between g++ versions | |
873 | ||
874 | As a rule, the first two digits of your g++ and libg++ should be the | |
875 | same. Normally when you do an upgrade in the ``minor version number'' | |
876 | (2.5.7 to 2.5.8, say) there isn't a need to rebuild libg++, but there | |
877 | have been a couple of exceptions in the past. | |
878 | ||
879 | @node co-existing versions, Installing on Linux, Rebuild libg++?, installation | |
880 | @section I want several versions of g++ and libg++ to co-exist. | |
881 | ||
882 | I recommend against using the @code{-V} flag to make multiple versions | |
883 | of gcc/g++ co-exist, unless they are different minor releases that can use | |
884 | the same compiled version of libg++. The reason is that all these | |
885 | versions will try to use the same libg++ version, which usually will | |
886 | not work. | |
887 | ||
888 | Instead, use the @code{--prefix} flag when configuring gcc. Use a | |
889 | different value of @code{--prefix} for each gcc version. Use the | |
890 | same value of @code{--prefix} when configuring libg++. You can then | |
891 | have any number of co-existing gcc/libg++ pairs. Symbolic links can | |
892 | be used so that users don't need to put all these different directories | |
893 | on their paths. | |
894 | ||
895 | One possible system to use is to set @code{--prefix} to | |
896 | @file{/usr/local/gcc-2.x.y} for version 2.x.y of gcc, and to link | |
897 | whichever version of gcc you wish to be the default into | |
898 | @file{/usr/local/bin/gcc} and @file{/usr/local/bin/g++}. | |
899 | ||
900 | @node Installing on Linux, Linux Slackware 3.0, co-existing versions, installation | |
901 | @section Trouble installing g++ and libg++ on Linux | |
902 | ||
903 | ``I've downloaded the latest g++ and libg++ and I'm trying to install | |
904 | them on Linux, and I'm having lots of problems.'' | |
905 | ||
906 | @cindex Linux | |
907 | FSF releases of libg++ won't install on Linux unchanged, since Linux | |
908 | uses are part of the libio library from libg++ for its standard C | |
909 | library, only this is changed in a way that it clashes with libg++. | |
910 | This means that you'll need a patched version of libg++ for it to | |
911 | work. | |
912 | ||
913 | If you want to upgrade to a new gcc/libg++ combination, the easiest | |
914 | thing to do is to grab the prebuilt versions of gcc and libg++ for Linux | |
915 | from @file{ftp://tsx-11.mit.edu/pub/linux/packages/GCC}. Follow the | |
916 | directions carefully. If you want to build from source, you'll need | |
917 | a patch for libg++; the Linux developers have named the patched libg++ | |
918 | version libg++-2.7.1.3 and there is a patch file in the above-named | |
919 | directory. | |
920 | ||
921 | See @file{http://sunsite.unc.edu/LDP/HOWTO/GCC-HOWTO.html}, | |
922 | the Linux GCC HOWTO, for more on gcc/g++ and Linux. | |
923 | ||
924 | Linux is in the process of switching over to the GNU C library, version | |
925 | 2, which will become Linux libc version 6. Once this process is | |
926 | complete, there's a good chance that the installation process on Linux | |
927 | will be smoother, but only experts should try making this new library | |
928 | work at this point. | |
929 | ||
930 | @node Linux Slackware 3.0, , Installing on Linux, installation | |
931 | @section Problems with g++ on Linux Slackware 3.0 | |
932 | ||
933 | @cindex Slackware | |
934 | @cindex Linux Slackware | |
935 | ``When I try to compile the traditional Hello, world program on Linux, | |
936 | the compiler can't find @file{iostream.h}. What's the deal?'' | |
937 | ||
938 | You probably have the Slackware 3.0 release. There's an error in the | |
939 | setup. It's easy to fix, though; log in as root, and make a symbolic | |
940 | link: | |
941 | ||
942 | @example | |
943 | ln -s /usr/lib/g++-include /usr/include/g++ | |
944 | @end example | |
945 | ||
946 | @node evolution, User Problems, installation, Top | |
947 | @chapter The Evolution of g++ | |
948 | ||
949 | This chapter discusses the evolution of g++ and describes what can be expected | |
950 | in the future. | |
951 | ||
952 | @menu | |
953 | * version 2.7.x:: What's changed in 2.7.x from earlier versions | |
954 | * libstdc++:: The GNU C++ standard library | |
955 | * new work:: What's been done since 2.7.x | |
956 | * egcs:: The Experimental GNU Compiler System | |
957 | * When?:: When can I get all this new stuff? | |
958 | @end menu | |
959 | ||
960 | @node version 2.7.x, libstdc++, evolution, evolution | |
961 | @section What's new in version 2.7.x of gcc/g++ | |
962 | ||
963 | The current version of gcc/g++ is 2.7.2.2, released February 10, 1997. | |
964 | The only change between 2.7.2.1 and 2.7.2.2 is that support was added | |
965 | for using the GNU C library, version 2, on Linux; users not interested | |
966 | in that functionality have no reason to upgrade. | |
967 | The previous version of gcc/g++ is 2.7.2.1, released August 14, 1996. | |
968 | The current version of libg++ is 2.7.2, released July 4, 1996. | |
969 | ||
970 | Note that gcc 2.7.2.1 just consists of several small patches to | |
971 | gcc-2.7.2. The release is mainly | |
972 | intended to fix platform-specific bugs and does not affect the C++ | |
973 | ``front end'' of the compiler (the part that parses your C++ code). | |
974 | ||
975 | The 2.7.x releases represent a great deal of work on the part of the g++ | |
976 | maintainers to fix outstanding bugs and move the compiler closer to the | |
977 | current ANSI/ISO standards committee's working paper, including | |
978 | supporting many of the new features that have been added to the | |
979 | language. I recommend that everyone read the NEWS file contained in the | |
980 | distribution (and that system administrators make the file available to | |
981 | their users). I've borrowed liberally from this file here. | |
982 | ||
983 | @cindex C++ working paper | |
984 | If any features seem unfamiliar, you will probably want to | |
985 | look at the recently-released public review copy of the C++ Working | |
986 | Paper. A new draft, dated 2 December 1996, has been released for | |
987 | public comment. You can find it on the web at | |
988 | @file{http://www.cygnus.com/misc/wp/} or | |
989 | @file{http://www.maths.warwick.ac.uk/c++/pub/wp/html/cd2/}. | |
990 | See | |
991 | @file{http://www.setech.com/x3.html} | |
992 | or | |
993 | @file{http://www.maths.warwick.ac.uk/c++/pub/} to download the | |
994 | document in PostScript, PDF (Adobe Acrobat), HTML, or ASCII | |
995 | form. | |
996 | ||
997 | Here are the main points: | |
998 | ||
999 | @itemize @bullet | |
1000 | @item | |
1001 | @cindex for scope | |
1002 | As described above, the scope of variables declared in the | |
1003 | initialization part of a for statement has been changed; such variables | |
1004 | are now visible only in the loop body. Use @code{-fno-for-scope} to get | |
1005 | the old behavior. You'll need this flag to build groff version 1.09, | |
1006 | Ptolemy, and many other free software packages. | |
1007 | ||
1008 | @item | |
1009 | @cindex vtable duplication | |
1010 | Code that does not use #pragma interface/implementation will most | |
1011 | likely shrink dramatically, as g++ now only emits the vtable for a | |
1012 | class in the translation unit where its first non-inline, non-abstract | |
1013 | virtual function is defined. | |
1014 | ||
1015 | @item | |
1016 | @cindex automatic template instantiation | |
1017 | Support for automatic template instantiation has @emph{not} been enabled | |
1018 | in the official distribution, due to a disagreement over design philosophies. | |
1019 | But you can get a patch from Cygnus to turn it on; retrieve the patch | |
1020 | from @file{ftp://ftp.cygnus.com/pub/g++/gcc-2.7.2-repo.gz} to patch | |
1021 | gcc-2.7.2 (there are also patches for earlier gcc versions). | |
1022 | ||
1023 | @item | |
1024 | @cindex exception handling, 2.7.0 | |
1025 | ||
1026 | @xref{exceptions} | |
1027 | ||
1028 | @item | |
1029 | @cindex run-time type identification | |
1030 | Support for Run-Time Type Identification has been added with @code{-frtti}. | |
1031 | This support is still in alpha; one major restriction is that any file | |
1032 | compiled with @code{-frtti} must include @code{<typeinfo>} (@emph{not} | |
1033 | @code{typeinfo.h} as the NEWS file says). | |
1034 | Also, all C++ code you link with (including libg++) has to be built with | |
1035 | @code{-frtti}, so it's still tricky to use. | |
1036 | ||
1037 | @item | |
1038 | @cindex compiler-generated operators | |
1039 | Synthesis of compiler-generated constructors, destructors and | |
1040 | assignment operators is now deferred until the functions are used. | |
1041 | ||
1042 | @item | |
1043 | @cindex assignment in conditional expressions | |
1044 | The parsing of expressions such as @code{a ? b : c = 1} | |
1045 | has changed from | |
1046 | @code{(a ? b : c) = 1} to @code{a ? b : (c = 1)}. This is a new C/C++ | |
1047 | incompatibility brought to you by the ANSI/ISO standards committee. | |
1048 | ||
1049 | @item | |
1050 | @cindex new operator keywords | |
1051 | The operator keywords and, and_eq, bitand, bitor, compl, not, not_eq, | |
1052 | or, or_eq, xor and xor_eq are now supported. Use @code{-ansi} or | |
1053 | @code{-foperator-names} to enable them. | |
1054 | ||
1055 | @item | |
1056 | @cindex explicit keyword | |
1057 | The @code{explicit} keyword is now supported. @code{explicit} is used to mark | |
1058 | constructors and type conversion operators that should not be used | |
1059 | implicitly. | |
1060 | ||
1061 | @item | |
1062 | @cindex user-defined type conversion | |
1063 | Handling of user-defined type conversion has been improved. | |
1064 | ||
1065 | @item | |
1066 | @cindex explicit template instantiation | |
1067 | Explicit instantiation of template methods is now supported. Also, | |
1068 | @code{inline template class foo<int>;} | |
1069 | can be used to emit only the vtable | |
1070 | for a template class. | |
1071 | ||
1072 | @item | |
1073 | @cindex -fcheck-new | |
1074 | With -fcheck-new, g++ will check the return value of all calls to | |
1075 | operator new, and not attempt to modify a returned null pointer. | |
1076 | ||
1077 | @item | |
1078 | collect2 now demangles linker output, and c++filt has become part of | |
1079 | the gcc distribution. | |
1080 | ||
1081 | @item | |
1082 | Improvements to template instantiation: only members actually used | |
1083 | are instantiated. (Actually this is not quite true: some inline | |
1084 | templates that are not successfully inlined may be expanded even | |
1085 | though they are not needed). | |
1086 | ||
1087 | @end itemize | |
1088 | ||
1089 | @node libstdc++, new work, version 2.7.x, evolution | |
1090 | @section The GNU Standard C++ Library | |
1091 | ||
1092 | The GNU Standard C++ Library (also called the ``GNU ANSI C++ Library'' | |
1093 | in places in the code) is not libg++, though it is included in the | |
1094 | libg++ distribution. Rather, it contains classes and functions | |
1095 | required by the ANSI/ISO standard. The copyright conditions are the | |
1096 | same as those for for the iostreams classes; the LGPL is not used | |
1097 | (@pxref{legalities}). | |
1098 | ||
1099 | This library, libstdc++, is in the libg++ distribution in versions 2.6.2 | |
1100 | and later. It requires at least gcc 2.6.3 to build the libg++-2.6.2 | |
1101 | version; use at least gcc 2.7.0 to build the libg++ 2.7.0 version. It | |
1102 | contains a hacked-up version of HP's implementation of the Standard | |
1103 | Template Library (@pxref{Standard Template Library}). I've | |
1104 | successfully used this Standard Template Library version to build | |
1105 | a number of the demos you'll see on various web pages. | |
1106 | ||
1107 | As of version 2.7.0, the streams classes are now in libstdc++ instead of | |
1108 | libg++, and libiostream is being phased out (don't use it). The g++ | |
1109 | program searches this library. | |
1110 | ||
1111 | The maintainers of libg++ have de-emphasized work on the older libg++ classes | |
1112 | in favor of enhancing libstdc++ to cover the full language, so while libg++ | |
1113 | will always be available, enhancements to it should not be expected. | |
1114 | ||
1115 | @node new work, egcs, libstdc++, evolution | |
1116 | @section What can we expect in future gcc releases? | |
1117 | ||
1118 | A great deal of work has gone into enhancements to the C++ front end, as well | |
1119 | as to other aspects of the compiler. | |
1120 | ||
1121 | The next major release(s) of gcc/g++ can be expected to have the following | |
1122 | features: | |
1123 | ||
1124 | @itemize @bullet | |
1125 | @cindex new template implementation | |
1126 | @item | |
1127 | A completely new template implementation, much closer to the draft | |
1128 | standard. Limitations in 2.7.2.x concerning inlining template functions | |
1129 | will be eliminated. Static template data members, template class member | |
1130 | functions, partial specification, and default template arguments will be | |
1131 | supported. An instantiation method resembling that used in Borland C++ | |
1132 | (instantiating functions possibly in multiple .o files and using weak | |
1133 | symbols to link correctly) will be provided, in addition to other | |
1134 | options. The SGI version of STL will be shipped with libstdc++ and will | |
1135 | compile unchanged. | |
1136 | ||
1137 | @item | |
1138 | @cindex new exception implementation | |
1139 | Exception handling has been re-worked; exceptions will work together | |
1140 | with optimization. | |
1141 | Actually, there are two separate implementations: one based on setjmp/longjmp | |
1142 | and designed to be highly portable, and one designed to be more efficient but | |
1143 | requiring more processor-specific support (getting exceptions right has proven | |
1144 | to be extremely difficult and has been the chief obstacle to getting a new | |
1145 | release out). | |
1146 | ||
1147 | @item | |
1148 | @cindex RTTI | |
1149 | RTTI has been re-done to work correctly and is on by default. | |
1150 | ||
1151 | @item | |
1152 | @cindex overloading | |
1153 | Overloading has been re-worked to conform to the latest draft of the | |
1154 | standard. | |
1155 | @end itemize | |
1156 | ||
1157 | Features that are still missing include namespaces and templates as | |
1158 | template arguments. | |
1159 | ||
1160 | @node egcs, When?, new work, evolution | |
1161 | @section What's this I hear about egcs? | |
1162 | ||
1163 | The egcs effort is a new effort to merge several threads of gcc | |
1164 | development and to provide a faster development process. | |
1165 | For more information see @file{http://www.cygnus.com/egcs/}. | |
1166 | ||
1167 | @node When?, , egcs, evolution | |
1168 | @section OK, when can I get this stuff? | |
1169 | ||
1170 | The FSF has a policy of never announcing release dates in advance. | |
1171 | I'm sure this is frustrating to a lot of people, since it's taken | |
1172 | so long, and this frustration was one of the reasons the egcs effort | |
1173 | was created. An egcs release should be expected to occur in the | |
1174 | very near future. [ More on this next time ]. | |
1175 | ||
1176 | @node User Problems, legalities, evolution, Top | |
1177 | @chapter User Problems | |
1178 | ||
1179 | @menu | |
1180 | * missing virtual table:: | |
1181 | * for scope:: | |
1182 | * const constructor:: | |
1183 | * unused parameter warnings:: | |
1184 | * jump crosses initialization:: | |
1185 | * Demangler:: | |
1186 | * static data members:: | |
1187 | * internal compiler error:: | |
1188 | * bug reports:: | |
1189 | * porting to g++:: | |
1190 | * name mangling:: | |
1191 | * problems linking with other libraries:: | |
1192 | * documentation:: | |
1193 | * templates:: | |
1194 | * undefined templates:: | |
1195 | * redundant templates:: | |
1196 | * Standard Template Library:: | |
1197 | * STL and string:: | |
1198 | * exceptions:: | |
1199 | * namespaces:: | |
1200 | * agreement with standards:: | |
1201 | * compiling standard libraries:: | |
1202 | * debugging on SVR4 systems:: | |
1203 | * debugging problems on Solaris:: | |
1204 | * X11 conflicts with libg++:: | |
1205 | * assignment to streams:: | |
1206 | @end menu | |
1207 | ||
1208 | @node missing virtual table, for scope, User Problems, User Problems | |
1209 | @section Linker complains about missing virtual table | |
1210 | ||
1211 | ``I'm getting a message complaining about an undefined virtual table. Is | |
1212 | this a compiler bug?'' | |
1213 | ||
1214 | (On platforms that run neither collect nor the GNU linker, like Solaris, | |
1215 | you may see an odd undefined symbol like "_vt.3foo", where foo is a | |
1216 | class name). | |
1217 | ||
1218 | This is probably because you are missing a definition for the first | |
1219 | (non-inline) virtual function of the class. Since gcc-2.7.0, g++ uses | |
1220 | a trick borrowed from cfront: the .o file containing the definition for | |
1221 | the first non-inline virtual function for the class will also contain | |
1222 | the virtual function table. | |
1223 | ||
1224 | @node for scope, const constructor, missing virtual table, User Problems | |
1225 | @section gcc-2.7.0 breaks declarations in "for" statements! | |
1226 | ||
1227 | @cindex declarations in for statements | |
1228 | @cindex for statements: declarations | |
1229 | ||
1230 | gcc-2.7.0 implements the new ANSI/ISO rule on the scope of variables | |
1231 | declared in for loops. | |
1232 | ||
1233 | @example | |
1234 | for (int i = 1; i <= 10; i++) @{ | |
1235 | // do something here | |
1236 | @} | |
1237 | foo(i); | |
1238 | @end example | |
1239 | ||
1240 | In the above example, most existing C++ compilers would pass the | |
1241 | value 11 to the function @code{foo}. In gcc 2.7 and in the ANSI/ISO | |
1242 | working paper, the scope of @code{i} is only the for loop body, so | |
1243 | this is an error. So that old code can be compiled, the new gcc has | |
1244 | a flag @code{-fno-for-scope} that causes the old rule to be used. | |
1245 | @cindex -fno-for-scope | |
1246 | ||
1247 | As of 2.7.1, the compiler attempts to issue warnings about code that | |
1248 | has different meanings under the two sets of rules, but the code is | |
1249 | not perfect: the intent was that code that has valid, but different, | |
1250 | meanings under the ARM rules and the working paper rules would give | |
1251 | warnings but have the new behavior, and this doesn't seem to happen. | |
1252 | ||
1253 | The @code{-ffor-scope} flag under 2.7.1 and 2.7.2 gives the 2.7.0 behavior. | |
1254 | ||
1255 | @node const constructor, unused parameter warnings, for scope, User Problems | |
1256 | @section g++ seems to want a const constructor. What's that? | |
1257 | ||
1258 | gcc-2.7.1 introduced a bug that causes the compiler to ask for a | |
1259 | const constructor (there's no such thing in C++) in certain situations | |
1260 | where a const object appears in a template class. Most cases have been | |
1261 | fixed in gcc-2.7.2, but unfortunately not all. Still, if you're running | |
1262 | gcc-2.7.1 and have this problem, upgrade to 2.7.2; it is a vast improvement. | |
1263 | ||
1264 | @cindex ObjectSpace<STL> | |
1265 | ||
1266 | The default constructor for the template @code{pair} in ObjectSpace's | |
1267 | implementation of STL triggers the bug in one place, for gcc 2.7.2. If | |
1268 | you're using ObjectSpace<STL> and having this problem, simply | |
1269 | change the default constructor from | |
1270 | ||
1271 | @example | |
1272 | os_pair () : first (T1 ()), second (T2 ()) @{@} | |
1273 | @end example | |
1274 | ||
1275 | to just | |
1276 | ||
1277 | @example | |
1278 | os_pair () @{@} | |
1279 | @end example | |
1280 | ||
1281 | Once this is done, ObjectSpace<STL> works fairly well. | |
1282 | ||
1283 | @node unused parameter warnings, jump crosses initialization, const constructor, User Problems | |
1284 | @section How to silence ``unused parameter'' warnings | |
1285 | ||
1286 | @cindex -Wall | |
1287 | @cindex -Wunused | |
1288 | ||
1289 | ``When I use @code{-Wall} (or @code{-Wunused}), g++ warns about | |
1290 | unused parameters. But the parameters have to be there, for use | |
1291 | in derived class functions. How do I get g++ to stop complaining?'' | |
1292 | ||
1293 | The answer is to simply omit the names of the unused parameters when | |
1294 | defining the function. This makes clear, both to g++ and to readers | |
1295 | of your code, that the parameter is unused. For example: | |
1296 | ||
1297 | @example | |
1298 | int Foo::bar(int arg) @{ return 0; @} | |
1299 | @end example | |
1300 | ||
1301 | will give a warning for the unused parameter @code{arg}. To suppress | |
1302 | the warning write | |
1303 | ||
1304 | @example | |
1305 | int Foo::bar(int) @{ return 0; @} | |
1306 | @end example | |
1307 | ||
1308 | @node jump crosses initialization, Demangler, unused parameter warnings, User Problems | |
1309 | @section g++ objects to a declaration in a case statement | |
1310 | ||
1311 | ``The compiler objects to my declaring a variable in one of the branches | |
1312 | of a case statement. Earlier versions used to accept this code. Why?'' | |
1313 | ||
1314 | The draft standard does not allow a goto or a jump to a case label to | |
1315 | skip over an initialization of a variable or a class object. For | |
1316 | example: | |
1317 | ||
1318 | @example | |
1319 | switch ( i ) @{ | |
1320 | case 1: | |
1321 | Object obj(0); | |
1322 | ... | |
1323 | break; | |
1324 | case 2: | |
1325 | ... | |
1326 | break; | |
1327 | @} | |
1328 | @end example | |
1329 | ||
1330 | The reason is that @code{obj} is also in scope in the rest of the switch | |
1331 | statement. | |
1332 | ||
1333 | As of version 2.7.0, the compiler will object that the jump to the | |
1334 | second case level crosses the initialization of @code{obj}. Older | |
1335 | compiler versions would object only if class Object has a destructor. | |
1336 | In either case, the solution is to add a set of curly braces around | |
1337 | the case branch: | |
1338 | ||
1339 | @example | |
1340 | case 1: | |
1341 | @{ | |
1342 | Object obj(0); | |
1343 | ... | |
1344 | break; | |
1345 | @} | |
1346 | @end example | |
1347 | ||
1348 | @node Demangler, static data members, jump crosses initialization, User Problems | |
1349 | @section Where can I find a demangler? | |
1350 | ||
1351 | @cindex demangler program | |
1352 | A g++-compatible demangler named @code{c++filt} can be found in the | |
1353 | @file{binutils} distribution. This distribution (which also contains | |
1354 | the GNU linker) can be found at any GNU archive site. | |
1355 | ||
1356 | As of version 2.7.0, @code{c++filt} is included with gcc and is | |
1357 | installed automatically. Even better, it is used by the @code{collect} | |
1358 | linker, so you don't see mangled symbols anymore (except on platforms | |
1359 | that use neither collect nor the GNU linker, like Solaris). | |
1360 | ||
1361 | @node static data members, internal compiler error, Demangler, User Problems | |
1362 | @section Linker reports undefined symbols for static data members | |
1363 | ||
1364 | @cindex Static data members | |
1365 | ``g++ reports undefined symbols for all my static data members when I link, | |
1366 | even though the program works correctly for compiler XYZ. What's going on?'' | |
1367 | ||
1368 | The problem is almost certainly that you don't give definitions for | |
1369 | your static data members. If you have | |
1370 | ||
1371 | @example | |
1372 | class Foo @{ | |
1373 | ... | |
1374 | void method(); | |
1375 | static int bar; | |
1376 | @}; | |
1377 | @end example | |
1378 | ||
1379 | you have only declared that there is an int named Foo::bar and a member | |
1380 | function named Foo::method that is defined somewhere. You still need to | |
1381 | define @emph{both} method() and bar in some source file. According to | |
1382 | the draft ANSI standard, you must supply an initializer, such as | |
1383 | ||
1384 | @example | |
1385 | int Foo::bar = 0; | |
1386 | @end example | |
1387 | ||
1388 | @noindent | |
1389 | in one (and only one) source file. | |
1390 | ||
1391 | @node internal compiler error, bug reports, static data members, User Problems | |
1392 | @section What does ``Internal compiler error'' mean? | |
1393 | ||
1394 | It means that the compiler has detected a bug in itself. Unfortunately, | |
1395 | g++ still has many bugs, though it is a lot better than it used to be. | |
1396 | If you see this message, please send in a complete bug report (see next | |
1397 | section). | |
1398 | ||
1399 | @node bug reports, porting to g++, internal compiler error, User Problems | |
1400 | @section I think I have found a bug in g++. | |
1401 | ||
1402 | @cindex Bug in g++, newly found | |
1403 | ``I think I have found a bug in g++, but I'm not sure. How do I know, | |
1404 | and who should I tell?'' | |
1405 | ||
1406 | @cindex Manual, for gcc | |
1407 | First, see the excellent section on bugs and bug reports in the gcc manual | |
1408 | (which is included in the gcc distribution). As a short summary of that | |
1409 | section: if the compiler gets a fatal signal, for any input, it's a bug | |
1410 | (newer versions of g++ will ask you to send in a bug report when they | |
1411 | detect an error in themselves). Same thing for producing invalid | |
1412 | assembly code. | |
1413 | ||
1414 | When you report a bug, make sure to describe your platform (the type of | |
1415 | computer, and the version of the operating system it is running) and the | |
1416 | version of the compiler that you are running. See the output of the | |
1417 | command @code{g++ -v} if you aren't sure. Also provide enough code | |
1418 | so that the g++ maintainers can duplicate your bug. Remember that the | |
1419 | maintainers won't have your header files; one possibility is to send | |
1420 | the output of the preprocessor (use @code{g++ -E} to get this). This | |
1421 | is what a ``complete bug report'' means. | |
1422 | ||
1423 | I will add some extra notes that are C++-specific, since the notes from | |
1424 | the gcc documentation are generally C-specific. | |
1425 | ||
1426 | @cindex g++ bug report | |
1427 | First, mail your bug report to "bug-g++@@prep.ai.mit.edu". You may also | |
1428 | post to @file{gnu.g++.bug}, but it's better to use mail, particularly if you | |
1429 | have any doubt as to whether your news software generates correct reply | |
1430 | addresses. Don't mail C++ bugs to bug-gcc@@prep.ai.mit.edu. | |
1431 | ||
1432 | @strong{News:} as I write this (late February 1996) the gateway | |
1433 | connecting the bug-g++ mailing list and the @file{gnu.g++.bug} newsgroup | |
1434 | is (temporarily?) broken. Please mail, do not post bug reports. | |
1435 | ||
1436 | @cindex libg++ bug report | |
1437 | If your bug involves libg++ rather than the compiler, mail to | |
1438 | bug-lib-g++@@prep.ai.mit.edu. If you're not sure, choose one, and if you | |
1439 | guessed wrong, the maintainers will forward it to the other list. | |
1440 | ||
1441 | @cindex C++, reference books | |
1442 | @cindex ARM [Annotated C++ Ref Manual] | |
1443 | Second, if your program does one thing, and you think it should do | |
1444 | something else, it is best to consult a good reference if in doubt. | |
1445 | The standard reference is the draft working paper from the ANSI/ISO | |
1446 | C++ standardization committee, which you can get on the net. | |
1447 | For PostScript and PDF (Adobe Acrobat) versions, see the | |
1448 | archive at @file{ftp://research.att.com/dist/stdc++/WP}. For HTML and ASCII | |
1449 | versions, see @file{ftp://ftp.cygnus.com/pub/g++}. On the World Wide Web, see | |
1450 | @file{http://www.cygnus.com/misc/wp/}. | |
1451 | ||
1452 | An older | |
1453 | standard reference is "The Annotated C++ Reference Manual", by Ellis and | |
1454 | Stroustrup (copyright 1990, ISBN #0-201-51459-1). This is what they're | |
1455 | talking about on the net when they refer to ``the ARM''. But you should | |
1456 | know that changes have been made to the language since then. | |
1457 | ||
1458 | The ANSI/ISO C++ standards committee have adopted some changes to the | |
1459 | C++ language since the publication of the original ARM, and newer | |
1460 | versions of g++ (2.5.x and later) support some of these changes, notably | |
1461 | the mutable keyword (added in 2.5.0), the bool type (added in 2.6.0), | |
1462 | and changes in the scope of variables defined in for statements (added | |
1463 | in 2.7.0). | |
1464 | You can obtain an addendum to the ARM explaining many of these changes by FTP | |
1465 | from @file{ftp://ftp.std.com/AW/stroustrup2e/new_iso.ps}. | |
1466 | ||
1467 | @cindex AT&T cfront | |
1468 | Note that the behavior of (any version of) AT&T's "cfront" compiler is | |
1469 | NOT the standard for the language. | |
1470 | ||
1471 | @node porting to g++, name mangling, bug reports, User Problems | |
1472 | @section Porting programs from other compilers to g++ | |
1473 | ||
1474 | ``I have a program that runs on <some other C++ compiler>, and I want | |
1475 | to get it running under g++. Is there anything I should watch out | |
1476 | for?'' | |
1477 | ||
1478 | @cindex Porting to g++ | |
1479 | ||
1480 | Note that g++ supports many of the newer keywords that have recently | |
1481 | been added to the language. Your other C++ compiler may not support | |
1482 | them, so you may need to rename variables and members that conflict | |
1483 | with these keywords. | |
1484 | ||
1485 | There are two other reasons why a program that worked under one compiler | |
1486 | might fail under another: your program may depend on the order of | |
1487 | evaluation of side effects in an expression, or it may depend on the | |
1488 | lifetime of a temporary (you may be assuming that a temporary object | |
1489 | "lives" longer than the standard guarantees). As an example of the | |
1490 | first: | |
1491 | ||
1492 | @example | |
1493 | void func(int,int); | |
1494 | ||
1495 | int i = 3; | |
1496 | func(i++,i++); | |
1497 | @end example | |
1498 | ||
1499 | @cindex Order of evaluation, problems in porting | |
1500 | Novice programmers think that the increments will be evaluated in strict | |
1501 | left-to-right order. Neither C nor C++ guarantees this; the second | |
1502 | increment might happen first, for example. func might get 3,4, or it | |
1503 | might get 4,3. | |
1504 | ||
1505 | @cindex Classes, problems in porting | |
1506 | @cindex Problems in porting, class | |
1507 | The second problem often happens with classes like the libg++ String | |
1508 | class. Let's say I have | |
1509 | ||
1510 | @example | |
1511 | String func1(); | |
1512 | void func2(const char*); | |
1513 | @end example | |
1514 | ||
1515 | and I say | |
1516 | ||
1517 | @example | |
1518 | func2(func1()); | |
1519 | @end example | |
1520 | ||
1521 | because I know that class String has an "operator const char*". So what | |
1522 | really happens is | |
1523 | ||
1524 | @example | |
1525 | func2(func1().convert()); | |
1526 | @end example | |
1527 | ||
1528 | @cindex temporaries | |
1529 | where I'm pretending I have a convert() method that is the same as the | |
1530 | cast. This is unsafe in g++ versions before 2.6.0, because the | |
1531 | temporary String object may be deleted after its last use (the call to | |
1532 | the conversion function), leaving the pointer pointing to garbage, so by | |
1533 | the time func2 is called, it gets an invalid argument. | |
1534 | ||
1535 | @cindex ANSI draft standard | |
1536 | Both the cfront and the old g++ behaviors are legal according to the ARM, | |
1537 | but the powers that be have decided that compiler writers were given | |
1538 | too much freedom here. | |
1539 | ||
1540 | The ANSI C++ committee has now come to a resolution of the lifetime of | |
1541 | temporaries problem: they specify that temporaries should be deleted at | |
1542 | end-of-statement (and at a couple of other points). This means that g++ | |
1543 | versions before 2.6.0 now delete temporaries too early, and cfront | |
1544 | deletes temporaries too late. As of version 2.6.0, g++ does things | |
1545 | according to the new standard. | |
1546 | ||
1547 | @cindex Scope, problems in porting | |
1548 | @cindex Problems in porting, scope | |
1549 | For now, the safe way to write such code is to give the temporary a name, | |
1550 | which forces it to live until the end of the scope of the name. For | |
1551 | example: | |
1552 | ||
1553 | @example | |
1554 | String& tmp = func1(); | |
1555 | func2(tmp); | |
1556 | @end example | |
1557 | ||
1558 | Finally, like all compilers (but especially C++ compilers, it seems), | |
1559 | g++ has bugs, and you may have tweaked one. If so, please file a bug | |
1560 | report (after checking the above issues). | |
1561 | ||
1562 | @node name mangling, problems linking with other libraries, porting to g++, User Problems | |
1563 | @section Why does g++ mangle names differently from other C++ compilers? | |
1564 | ||
1565 | See the answer to the next question. | |
1566 | @cindex Mangling names | |
1567 | ||
1568 | @node problems linking with other libraries, documentation, name mangling, User Problems | |
1569 | @section Why can't g++ code link with code from other C++ compilers? | |
1570 | ||
1571 | ``Why can't I link g++-compiled programs against libraries compiled by | |
1572 | some other C++ compiler?'' | |
1573 | ||
1574 | @cindex Mangling names | |
1575 | @cindex Cygnus Support | |
1576 | Some people think that, | |
1577 | if only the FSF and Cygnus Support folks would stop being | |
1578 | stubborn and mangle names the same way that, say, cfront does, then any | |
1579 | g++-compiled program would link successfully against any cfront-compiled | |
1580 | library and vice versa. Name mangling is the least of the problems. | |
1581 | Compilers differ as to how objects are laid out, how multiple inheritance | |
1582 | is implemented, how virtual function calls are handled, and so on, so if | |
1583 | the name mangling were made the same, your programs would link against | |
1584 | libraries provided from other compilers but then crash when run. For this | |
1585 | reason, the ARM @emph{encourages} compiler writers to make their name mangling | |
1586 | different from that of other compilers for the same platform. | |
1587 | Incompatible libraries are then detected at link time, rather than at run | |
1588 | time. | |
1589 | @cindex ARM [Annotated C++ Ref Manual] | |
1590 | @cindex Compiler differences | |
1591 | ||
1592 | @node documentation, templates, problems linking with other libraries, User Problems | |
1593 | @section What documentation exists for g++ 2.x? | |
1594 | ||
1595 | @cindex g++, documentation | |
1596 | Relatively little. | |
1597 | While the gcc manual that comes with the distribution has some coverage | |
1598 | of the C++ part of the compiler, it focuses mainly on the C compiler | |
1599 | (though the information on the ``back end'' pertains to C++ as well). | |
1600 | Still, there is useful information on the command line options and the | |
1601 | #pragma interface and #pragma implementation directives in the manual, | |
1602 | and there is a useful section on template instantiation in the 2.6 version. | |
1603 | There is a Unix-style manual entry, "g++.1", in the gcc-2.x | |
1604 | distribution; the information here is a subset of what is in the manual. | |
1605 | ||
1606 | You can buy a nicely printed and bound copy of this manual from the FSF; | |
1607 | see above for ordering information. | |
1608 | ||
1609 | A draft of a document describing the g++ internals appears in the gcc | |
1610 | distribution (called g++int.texi); it is incomplete but gives lots of | |
1611 | information. | |
1612 | ||
1613 | For class libraries, there are several resources available: | |
1614 | ||
1615 | @itemize @bullet | |
1616 | @item | |
1617 | The libg++ distribution has a manual | |
1618 | @file{libg++/libg++.texi} describing the old libg++ classes, and | |
1619 | another manual @file{libio/iostream.texi} describing the iostreams | |
1620 | implementation. | |
1621 | @item | |
1622 | While there is no libg++-specific document describing the STL | |
1623 | implementation, SGI's web site, at @file{http://www.sgi.com/Technology/STL/}, | |
1624 | is an excellent resource. | |
1625 | @end itemize | |
1626 | ||
1627 | @node templates, undefined templates, documentation, User Problems | |
1628 | @section Problems with the template implementation | |
1629 | ||
1630 | @cindex g++, template support | |
1631 | @cindex Templates | |
1632 | ||
1633 | g++ does not implement a separate pass to instantiate template functions | |
1634 | and classes at this point; for this reason, it will not work, for the most | |
1635 | part, to declare your template functions in one file and define them in | |
1636 | another. The compiler will need to see the entire definition of the | |
1637 | function, and will generate a static copy of the function in each file | |
1638 | in which it is used. | |
1639 | ||
1640 | (The experimental template repository code (@pxref{repository}) that | |
1641 | can be added to 2.7.0 or later does implement a separate pass, but there | |
1642 | is still no searching of files that the compiler never saw). | |
1643 | ||
1644 | @cindex -fno-implicit-templates | |
1645 | For version 2.6.0, however, a new switch @code{-fno-implicit-templates} | |
1646 | was added; with this switch, templates are expanded only under user | |
1647 | control. I recommend that all g++ users that use templates read the | |
1648 | section ``Template Instantiation'' in the gcc manual (version 2.6.x | |
1649 | and newer). g++ now supports explicit template expansion using the | |
1650 | syntax from the latest C++ working paper: | |
1651 | ||
1652 | @example | |
1653 | template class A<int>; | |
1654 | template ostream& operator << (ostream&, const A<int>&); | |
1655 | @end example | |
1656 | ||
1657 | @cindex template limitations | |
1658 | As of version 2.6.3, there are still a few limitations in the template | |
1659 | implementation besides the above (thanks to Jason Merrill for this info): | |
1660 | These are still present in version 2.7.2, but a new implementation of | |
1661 | templates planned for version 2.8 will eliminate them. | |
1662 | ||
1663 | @enumerate 1 | |
1664 | @item | |
1665 | Static data member templates are not supported. You can work around | |
1666 | this by explicitly declaring the static variable for each template | |
1667 | specialization: | |
1668 | ||
1669 | @example | |
1670 | template <class T> struct A @{ | |
1671 | static T t; | |
1672 | @}; | |
1673 | ||
1674 | template <class T> T A<T>::t = 0; // gets bogus error | |
1675 | int A<int>::t = 0; // OK (workaround) | |
1676 | @end example | |
1677 | ||
1678 | (still a limitation in 2.7.2) | |
1679 | ||
1680 | @item | |
1681 | Template member names are not available when defining member function | |
1682 | templates. | |
1683 | ||
1684 | @example | |
1685 | template <class T> struct A @{ | |
1686 | typedef T foo; | |
1687 | void f (foo); | |
1688 | void g (foo arg) @{ ... @}; // this works | |
1689 | @}; | |
1690 | ||
1691 | template <class T> void A<T>::f (foo) @{ @} // gets bogus error | |
1692 | @end example | |
1693 | ||
1694 | @item | |
1695 | Templates are instantiated using the parser. This results in two | |
1696 | problems: | |
1697 | ||
1698 | a) Class templates are instantiated in some situations where such | |
1699 | instantiation should not occur. | |
1700 | ||
1701 | @example | |
1702 | template <class T> class A @{ @}; | |
1703 | A<int> *aip = 0; // should not instantiate A<int> (but does) | |
1704 | @end example | |
1705 | ||
1706 | b) Function templates cannot be inlined at the site of their | |
1707 | instantiation. | |
1708 | ||
1709 | @example | |
1710 | template <class T> inline T min (T a, T b) @{ return a < b ? a : b; @} | |
1711 | ||
1712 | void f () @{ | |
1713 | int i = min (1, 0); // not inlined | |
1714 | @} | |
1715 | ||
1716 | void g () @{ | |
1717 | int j = min (1, 0); // inlined | |
1718 | @} | |
1719 | @end example | |
1720 | ||
1721 | A workaround that works in version 2.6.1 and later is to specify | |
1722 | ||
1723 | @example | |
1724 | extern template int min (int, int); | |
1725 | @end example | |
1726 | ||
1727 | before @code{f()}; this will force it to be instantiated (though not | |
1728 | emitted). | |
1729 | ||
1730 | @item | |
1731 | Member function templates are always instantiated when their containing | |
1732 | class is. This is wrong. | |
1733 | @end enumerate | |
1734 | ||
1735 | @node undefined templates, redundant templates, templates, User Problems | |
1736 | @section I get undefined symbols when using templates | |
1737 | ||
1738 | (Thanks to Jason Merrill for this section). | |
1739 | ||
1740 | @cindex template instantiation | |
1741 | g++ does not automatically instantiate templates defined in other files. | |
1742 | Because of this, code written for cfront will often produce undefined | |
1743 | symbol errors when compiled with g++. You need to tell g++ which template | |
1744 | instances you want, by explicitly instantiating them in the file where they | |
1745 | are defined. For instance, given the files | |
1746 | ||
1747 | @file{templates.h}: | |
1748 | @example | |
1749 | template <class T> | |
1750 | class A @{ | |
1751 | public: | |
1752 | void f (); | |
1753 | T t; | |
1754 | @}; | |
1755 | ||
1756 | template <class T> void g (T a); | |
1757 | @end example | |
1758 | ||
1759 | @file{templates.cc}: | |
1760 | @example | |
1761 | #include "templates.h" | |
1762 | ||
1763 | template <class T> | |
1764 | void A<T>::f () @{ @} | |
1765 | ||
1766 | template <class T> | |
1767 | void g (T a) @{ @} | |
1768 | @end example | |
1769 | ||
1770 | ||
1771 | main.cc: | |
1772 | @example | |
1773 | #include "templates.h" | |
1774 | ||
1775 | main () | |
1776 | @{ | |
1777 | A<int> a; | |
1778 | a.f (); | |
1779 | g (a); | |
1780 | @} | |
1781 | @end example | |
1782 | ||
1783 | compiling everything with @code{g++ main.cc templates.cc} will result in | |
1784 | undefined symbol errors for @samp{A<int>::f ()} and @samp{g (A<int>)}. To | |
1785 | fix these errors, add the lines | |
1786 | ||
1787 | @example | |
1788 | template class A<int>; | |
1789 | template void g (A<int>); | |
1790 | @end example | |
1791 | ||
1792 | to the bottom of @samp{templates.cc} and recompile. | |
1793 | ||
1794 | @node redundant templates, Standard Template Library, undefined templates, User Problems | |
1795 | @section I get multiply defined symbols using templates | |
1796 | ||
1797 | You may be running into a bug that was introduced in version 2.6.1 | |
1798 | (and is still present in 2.6.3) that generated external linkage | |
1799 | for templates even when neither @code{-fexternal-templates} nor | |
1800 | @code{-fno-implicit-templates} is specified. There is a patch for | |
1801 | this problem at @* | |
1802 | @file{ftp://ftp.cygnus.com/pub/g++/gcc-2.6.3-template-fix}. | |
1803 | ||
1804 | I recommend either applying the patch or | |
1805 | using @code{-fno-implicit-templates} | |
1806 | together with explicit template instantiation as described in previous | |
1807 | sections. | |
1808 | ||
1809 | This bug is fixed in 2.7.0. | |
1810 | ||
1811 | @node Standard Template Library, STL and string, redundant templates, User Problems | |
1812 | @section Does g++ support the Standard Template Library? | |
1813 | ||
1814 | @cindex STL | |
1815 | @cindex Standard Template Library | |
1816 | The Standard Template Library (STL) uses many of the extensions that the | |
1817 | ANSI/ISO committee has made to templates, and g++ doesn't support | |
1818 | some of these yet. So if you grab HP's free implementation of STL it | |
1819 | isn't going to work. However, starting with libg++-2.6.2 libg++ contains a | |
1820 | hacked version of STL, based on work by Carsten Bormann, which permits | |
1821 | g++ to compile at least the containers (thanks to Per Bothner for this | |
1822 | text). | |
1823 | ||
1824 | Actually, as of libg++ version 2.7.2 most of this works quite well, most | |
1825 | of the time; | |
1826 | I've succeeded | |
1827 | in making significant use of it. | |
1828 | Almost all of the ObjectSpace examples (a set of | |
1829 | over 200 simple examples of STL usage) now work. | |
1830 | ||
1831 | When version 2.8.0 is out (with its complete redesign of the template | |
1832 | implementation) a much more complete implementation of the | |
1833 | STL (based on a newer free implementation from SGI) will be included. | |
1834 | In the meantime, a group at the Moscow Center for Sparc Technology has | |
1835 | a port of the SGI STL implementation that mostly works with gcc-2.7.2. | |
1836 | See | |
1837 | @file{http://www.ipmce.su/people/fbp/stl/stlport.html}. | |
1838 | ||
1839 | In addition, there are several commercial suppliers of STL implementations; | |
1840 | ObjectSpace's version supports gcc-2.7.x. | |
1841 | ||
1842 | Mumit Khan has produced an ``STL newbie guide'' with lots of information | |
1843 | on using STL with gcc. See | |
1844 | ||
1845 | @file{http://www.xraylith.wisc.edu/~khan/software/stl/STL.newbie.html} | |
1846 | ||
1847 | @node STL and string, exceptions, Standard Template Library, User Problems | |
1848 | @section I'm having problems mixing STL and the standard string class | |
1849 | ||
1850 | This is due to a bug in g++ version 2.7.2 and 2.7.2.1; the compiler | |
1851 | is confused by the operator declarations. There is an easy workaround, | |
1852 | however; just make sure that the @code{<string>} header is included | |
1853 | before any STL headers. That is, just say | |
1854 | ||
1855 | @example | |
1856 | #include <string> | |
1857 | @end example | |
1858 | ||
1859 | before any other @code{#include} directives. | |
1860 | ||
1861 | Unfortunately, this doesn't solve all problems; you may still have | |
1862 | difficulty with the relational operators !=, <=, >, and >=, thanks | |
1863 | to a conflict with the very general definition of these operators | |
1864 | in function.h. One trick that sometimes works is to try to use == | |
1865 | and < in your code instead of the other operators. Another is to | |
1866 | use a derived class of <string>. The only completely satisfactory | |
1867 | solution, I'm afraid, is to wait for the new release. | |
1868 | ||
1869 | @node exceptions, namespaces, STL and string, User Problems | |
1870 | @section Problems and limitations with exceptions | |
1871 | ||
1872 | Recent g++ versions provide limited support for exceptions. You must | |
1873 | provide the @code{-fhandle-exceptions} flag to enable exception | |
1874 | handling. As of version 2.7.2, exceptions may not work properly | |
1875 | (and you may get odd error messages when compiling) if you turn | |
1876 | on optimization (the @code{-O} flag). | |
1877 | ||
1878 | You must give the @code{-frtti} switch to enable catching | |
1879 | of derived exception objects with handlers for the base exception class; | |
1880 | if @code{-frtti} is not given, only exact type matching works. | |
1881 | ||
1882 | For exception handling to work with 2.7.0 your CPU must be a SPARC, | |
1883 | RS6000/PowerPC, 386/486/Pentium, or ARM. Release 2.7.1 added support | |
1884 | for the Alpha, and ``m68k is rumored to work on some platforms'' | |
1885 | and ``VAX may also work'' (according to Mike Stump). | |
1886 | @emph{It still doesn't work on HP-PA or MIPS platforms.} | |
1887 | ||
1888 | @node namespaces, agreement with standards, exceptions, User Problems | |
1889 | @section Does g++ support namespaces? | |
1890 | ||
1891 | As of version 2.7.2, g++ recognizes the keywords @code{namespace} and | |
1892 | @code{using}, and there is some rudimentary code present, but almost | |
1893 | nothing connected with namespaces works yet. It appears that this will | |
1894 | still be true when 2.8.0 is released. | |
1895 | ||
1896 | @node agreement with standards, compiling standard libraries, namespaces, User Problems | |
1897 | @section What are the differences between g++ and the ARM specification of C++? | |
1898 | ||
1899 | @cindex ARM [Annotated C++ Ref Manual] | |
1900 | @cindex exceptions | |
1901 | As of version 2.7.0, g++ has exception support on most but not all | |
1902 | platforms | |
1903 | (no support on MIPS-based platforms yet), but | |
956d6950 | 1904 | it doesn't work right if optimization is enabled, which means the |
5408ce78 JM |
1905 | exception |
1906 | implementation is still | |
1907 | not really ready for production use. | |
1908 | ||
1909 | ||
1910 | @cindex mutable | |
1911 | Some features that the ANSI/ISO standardization committee has voted in | |
1912 | that don't appear in the ARM are supported, notably the @code{mutable} | |
1913 | keyword, in version 2.5.x. 2.6.x adds support for the built-in boolean | |
1914 | type @code{bool}, with constants @code{true} and @code{false}. The | |
1915 | beginnings of run-time type identification are present, so there are | |
1916 | more reserved words: @code{typeid}, @code{static_cast}, | |
1917 | @code{reinterpret_cast}, @code{const_cast}, and @code{dynamic_cast}. | |
1918 | ||
1919 | @cindex g++ bugs | |
1920 | As with any beta-test compiler, there are bugs. You can help improve | |
1921 | the compiler by submitting detailed bug reports. | |
1922 | ||
1923 | One of the weakest areas of g++ other than templates is the resolution | |
1924 | of overloaded functions and operators in complex cases. The usual | |
1925 | symptom is that in a case where the ARM says that it is ambiguous which | |
1926 | function should be chosen, g++ chooses one (often the first one | |
1927 | declared). This is usually not a problem when porting C++ code from | |
1928 | other compilers to g++, but shows up as errors when code developed under | |
1929 | g++ is ported to other compilers. (I believe this is no longer a | |
1930 | significant problem in 2.7.0). | |
1931 | ||
1932 | [A full bug list would be very long indeed, so I won't put one here. | |
1933 | I may add a list of frequently-reported bugs and "non-bugs" like the | |
1934 | static class members issue mentioned above]. | |
1935 | ||
1936 | @node compiling standard libraries, debugging on SVR4 systems, agreement with standards, User Problems | |
1937 | @section Will g++ compile InterViews? The NIH class library? Rogue Wave? | |
1938 | ||
1939 | @cindex NIH class library | |
1940 | @cindex NIHCL with g++ | |
1941 | The NIH class library uses a non-portable, compiler-dependent hack | |
1942 | to initialize itself, which makes life difficult for g++ users. | |
1943 | It will not work without modification, and I don't know what modifications | |
1944 | are required or whether anyone has done them successfully. | |
1945 | ||
1946 | In short, it's not going to happen any time soon (previous FAQs referred | |
1947 | to patches that a new NIHCL release would hopefully contain, but this | |
1948 | hasn't happened). | |
1949 | ||
1950 | @strong{Note:} I thought I saw an item indicating that someone | |
1951 | @emph{had} patched NIHCL to work with g++. Any pointers? | |
1952 | ||
1953 | @cindex InterViews | |
1954 | I think that as of version 2.5.6, the standard g++ will compile the | |
1955 | standard 3.1 InterViews completely successfully. | |
1956 | Note that you'll need the @code{-fno-for-scope} flag | |
1957 | if you use gcc-2.7.0; with 2.7.2 you may be able to omit this flag | |
1958 | but you'll get warnings. | |
1959 | ||
1960 | @cindex Rogue Wave | |
1961 | According to Jason Merrill, gcc-2.7.0 and newer works with Rogue | |
1962 | Wave's @code{tools.h++} class library, but you may want to grab | |
1963 | @file{ftp://ftp.cygnus.com/pub/g++/Tools.h++-6.1-patch}. Again, | |
1964 | you'll need the @code{-fno-for-scope} flag since Rogue Wave hasn't | |
1965 | fixed their code to comply with the new standard yet. | |
1966 | ||
1967 | @node debugging on SVR4 systems, debugging problems on Solaris, compiling standard libraries, User Problems | |
1968 | @section Debugging on SVR4 systems | |
1969 | @cindex System VR4, debugging | |
1970 | ||
1971 | ``How do I get debugging to work on my System V Release 4 system?'' | |
1972 | ||
1973 | @cindex DWARF debug format | |
1974 | ||
1975 | Most systems based on System V Release 4 (except Solaris) encode symbolic | |
1976 | debugging information in a format known as `DWARF'. | |
1977 | ||
1978 | Although the GNU C compiler already knows how to write out symbolic debugging | |
1979 | information in the DWARF format, the GNU C++ compiler does not yet have this | |
1980 | feature yet. However, work is in progress for DWARF 2 debug support for | |
1981 | gcc and g++ and will be available in a future release (probably 2.8.0). | |
1982 | ||
1983 | @cindex stabs | |
1984 | @cindex --with-stabs | |
1985 | ||
1986 | In the meantime, you @emph{can} get g++ debugging under SVR4 systems by | |
1987 | configuring gcc with the @code{--with-stabs} option. This causes gcc to | |
1988 | use an alternate debugging format, one more like that used under SunOS4. | |
1989 | You won't need to do anything special to GDB; it will always understand | |
1990 | the ``stabs'' format. | |
1991 | ||
1992 | @node debugging problems on Solaris, X11 conflicts with libg++, debugging on SVR4 systems, User Problems | |
1993 | @section debugging problems on Solaris | |
1994 | ||
1995 | ``I'm on Solaris, and gdb says it doesn't know about some of my local | |
1996 | symbols. Help!'' | |
1997 | ||
1998 | This problem was introduced in gcc 2.7.2; debug symbols for | |
1999 | locals that aren't declared at the beginning of a block come out in the | |
2000 | wrong order, and gdb can't find such symbols. | |
2001 | ||
2002 | This problem is fixed in gcc-2.7.2.1. | |
2003 | ||
2004 | @node X11 conflicts with libg++, assignment to streams, debugging problems on Solaris, User Problems | |
2005 | @section X11 conflicts with libg++ in definition of String | |
2006 | @cindex String, conflicts in definition | |
2007 | ||
2008 | ``X11 and Motif define String, and this conflicts with the String class | |
2009 | in libg++. How can I use both together?'' | |
2010 | ||
2011 | One possible method is the following: | |
2012 | ||
2013 | @example | |
2014 | #define String XString | |
2015 | #include <X11/Intrinsic.h> | |
2016 | /* include other X11 and Motif headers */ | |
2017 | #undef String | |
2018 | @end example | |
2019 | ||
2020 | and remember to use the correct @code{String} or @code{XString} when | |
2021 | you declare things later. | |
2022 | ||
2023 | @node assignment to streams, , X11 conflicts with libg++, User Problems | |
2024 | @section Why can't I assign one stream to another? | |
2025 | ||
2026 | [ Thanks to Per Bothner and Jerry Schwarz for this section. ] | |
2027 | ||
2028 | Assigning one stream to another seems like a reasonable thing to do, but | |
2029 | it's a bad idea. Usually, this comes up because people want to assign | |
2030 | to @code{cout}. This is poor style, especially for libraries, and is | |
2031 | contrary to good object-oriented design. (Libraries that write directly | |
2032 | to @code{cout} are less flexible, modular, and object-oriented). | |
2033 | ||
2034 | The iostream classes do not allow assigning to arbitrary streams, because | |
2035 | this can violate typing: | |
2036 | ||
2037 | @example | |
2038 | ifstream foo ("foo"); | |
2039 | istrstream str(...); | |
2040 | foo = str; | |
2041 | foo->close (); /* Oops! Not defined for istrstream! */ | |
2042 | @end example | |
2043 | ||
2044 | @cindex assignment to cout | |
2045 | ||
2046 | The original cfront implementation of iostreams by Jerry Schwarz allows | |
2047 | you to assign to @code{cin}, @code{cout}, @code{cerr}, and @code{clog}, | |
2048 | but this is not part of the draft standard for iostreams and generally | |
2049 | isn't considered a good idea, so standard-conforming code shouldn't use | |
2050 | this technique. | |
2051 | ||
2052 | The GNU implementation of iostream did not support assigning to | |
2053 | @code{cin}, @code{cout}, @code{cerr}, and @code{clog} | |
2054 | for quite a while, but it now does, for backward | |
2055 | compatibility with cfront iostream (versions 2.6.1 and later of libg++). | |
2056 | ||
2057 | The ANSI/ISO C++ Working Paper does provide ways of changing the | |
2058 | streambuf associated with a stream. Assignment isn't allowed; | |
2059 | there is an explicit named member that must be used. | |
2060 | ||
2061 | However, it is not wise to do this, and the results are confusing. For | |
2062 | example: @code{fstream::rdbuf} is supposed to return the @emph{original} | |
2063 | filebuf, not the one you assigned. (This is not yet implemented in GNU | |
2064 | iostream.) This must be so because @code{fstream::rdbuf} is defined to | |
2065 | return a @code{filebuf *}. | |
2066 | ||
2067 | @node legalities, index, User Problems, Top | |
2068 | @chapter What are the rules for shipping code built with g++ and libg++? | |
2069 | @cindex Shipping rules | |
2070 | @cindex GPL [GNU Public License] | |
2071 | ||
2072 | ``Is it is possible to distribute programs for profit that are created | |
2073 | with g++ and use the g++ libraries?'' | |
2074 | ||
2075 | I am not a lawyer, and this is not legal advice. In any case, I have | |
2076 | little interest in telling people how to violate the spirit of the | |
2077 | GNU licenses without violating the letter. This section tells you | |
2078 | how to comply with the intention of the GNU licenses as best I understand | |
2079 | them. | |
2080 | ||
2081 | @cindex FSF [Free Software Foundation] | |
2082 | The FSF has no objection to your making money. Its only interest is that | |
2083 | source code to their programs, and libraries, and to modified versions of | |
2084 | their programs and libraries, is always available. | |
2085 | ||
2086 | The short answer is that you do not need to release the source to | |
2087 | your program, but you can't just ship a stripped executable either, | |
2088 | unless you use only the subset of libg++ that includes the iostreams | |
2089 | classes (see discussion below) or the new libstdc++ library (available | |
2090 | in libg++ 2.6.2 and later). | |
2091 | ||
2092 | Compiling your code with a GNU compiler does not affect its copyright; | |
2093 | it is still yours. However, in order to ship code that links in a GNU | |
2094 | library such as libg++ there are certain rules you must follow. The | |
2095 | rules are described in the file COPYING.LIB that accompanies gcc | |
2096 | distributions; it is also included in the libg++ distribution. | |
2097 | See that file for the exact rules. The agreement is called the | |
2098 | Library GNU Public License or LGPL. It is much "looser" than the | |
2099 | GNU Public License, or GPL, that covers must GNU programs. | |
2100 | ||
2101 | @cindex libg++, shipping code | |
2102 | Here's the deal: let's say that you use some version of libg++, | |
2103 | completely unchanged, in your software, and you want to ship only | |
2104 | a binary form of your code. You can do this, but there are several | |
2105 | special requirements. If you want to use libg++ but ship only object | |
2106 | code for your code, you have to ship source for libg++ (or ensure | |
2107 | somehow that your customer already has the source for the exact | |
2108 | version you are using), and ship your application in linkable form. | |
2109 | You cannot forbid your customer from reverse-engineering or extending | |
2110 | your program by exploiting its linkable form. | |
2111 | ||
2112 | @cindex libg++, modifying | |
2113 | Furthermore, if you modify libg++ itself, you must provide source | |
2114 | for your modifications (making a derived class does not count as | |
2115 | modifying the library -- that is "a work that uses the library"). | |
2116 | ||
2117 | @cindex special copying conditions for iostreams | |
2118 | For certain portions of libg++ that implement required parts of the C++ | |
2119 | language (such as iostreams and other standard classes), the FSF has | |
2120 | loosened the copyright requirement still more by adding the ``special | |
2121 | exception'' clause, which reads as follows: | |
2122 | ||
2123 | @quotation | |
2124 | As a special exception, if you link this library with files | |
2125 | compiled with GCC to produce an executable, this does not cause | |
2126 | the resulting executable to be covered by the GNU General Public License. | |
2127 | This exception does not however invalidate any other reasons why | |
2128 | the executable file might be covered by the GNU General Public License. | |
2129 | @end quotation | |
2130 | ||
2131 | If your only use of libg++ uses code with this exception, you may ship | |
2132 | stripped executables or license your executables under different | |
2133 | conditions without fear of violating an FSF copyright. It is the intent | |
2134 | of FSF and Cygnus that, as the other classes required by the ANSI/ISO | |
2135 | draft standard are developed, these will also be placed under this | |
2136 | ``special exception'' license. | |
2137 | The code in the new libstdc++ library, intended to implement standard | |
2138 | classes as defined by ANSI/ISO, is also licensed this way. | |
2139 | ||
2140 | To avoid coming under the influence of the LGPL, you can link with | |
2141 | @file{-liostream} rather than @file{-lg++} (for version 2.6.x and | |
2142 | earlier), or @file{-lstdc++} now that it is available. In version 2.7.0 | |
2143 | all the standard classes are in @file{-lstdc++}; you can do the link | |
2144 | step with @code{c++} instead of @code{g++} to search only the | |
2145 | @file{-lstdc++} library and avoid the LGPL'ed code in @file{-lg++}. | |
2146 | ||
2147 | If you wish to discuss legal issues connected with GNU software on the | |
2148 | net, please use @file{gnu.misc.discuss}, not the technical newsgroups. | |
2149 | ||
2150 | @node index, , legalities, Top | |
2151 | @comment node-name, next, previous, up | |
2152 | @appendix Concept Index | |
2153 | ||
2154 | @printindex cp | |
2155 | ||
2156 | @page | |
2157 | @contents | |
2158 | @bye |