1 |
21 |
jlechner |
|
2 |
|
|
GCC Frequently Asked Questions
|
3 |
|
|
|
4 |
|
|
The latest version of this document is always available at
|
5 |
|
|
[1]http://gcc.gnu.org/faq.html.
|
6 |
|
|
|
7 |
|
|
This FAQ tries to answer specific questions concerning GCC. For
|
8 |
|
|
general information regarding C, C++, resp. Fortran please check the
|
9 |
|
|
[2]comp.lang.c FAQ, [3]comp.std.c++ FAQ, and the [4]Fortran
|
10 |
|
|
Information page.
|
11 |
|
|
|
12 |
|
|
Other GCC-related FAQs: [5]libstdc++-v3, and [6]GCJ.
|
13 |
|
|
_________________________________________________________________
|
14 |
|
|
|
15 |
|
|
Questions
|
16 |
|
|
|
17 |
|
|
1. [7]General information
|
18 |
|
|
1. [8]What is the relationship between GCC and EGCS?
|
19 |
|
|
2. [9]What is an open development model?
|
20 |
|
|
3. [10]How do I get a bug fixed or a feature added?
|
21 |
|
|
4. [11]Does GCC work on my platform?
|
22 |
|
|
2. [12]Installation
|
23 |
|
|
1. [13]How to install multiple versions of GCC
|
24 |
|
|
2. [14]Dynamic linker is unable to find GCC libraries
|
25 |
|
|
3. [15]libstdc++/libio tests fail badly with --enable-shared
|
26 |
|
|
4. [16]GCC can not find GNU as/GNU ld
|
27 |
|
|
5. [17]cpp: Usage:... Error
|
28 |
|
|
6. [18]Optimizing the compiler itself
|
29 |
|
|
7. [19]Why does libiconv get linked into jc1 on Solaris?
|
30 |
|
|
3. [20]Testsuite problems
|
31 |
|
|
1. [21]How do I pass flags like -fnew-abi to the testsuite?
|
32 |
|
|
2. [22]How can I run the test suite with multiple options?
|
33 |
|
|
4. [23]Older versions of GCC
|
34 |
|
|
1. [24]Is there a stringstream / sstream for GCC 2.95.2?
|
35 |
|
|
5. [25]Miscellaneous
|
36 |
|
|
1. [26]Friend Templates
|
37 |
|
|
2. [27]dynamic_cast, throw, typeid don't work with shared
|
38 |
|
|
libraries
|
39 |
|
|
3. [28]Why do I need autoconf, bison, xgettext, automake, etc?
|
40 |
|
|
4. [29]Why can't I build a shared library?
|
41 |
|
|
5. [30]When building C++, the linker says my constructors,
|
42 |
|
|
destructors or virtual tables are undefined, but I defined
|
43 |
|
|
them
|
44 |
|
|
6. [31]Will GCC someday include an incremental linker?
|
45 |
|
|
_________________________________________________________________
|
46 |
|
|
|
47 |
|
|
General information
|
48 |
|
|
|
49 |
|
|
What is the relationship between GCC and EGCS?
|
50 |
|
|
|
51 |
|
|
In 1990/1991 gcc version 1 had reached a point of stability. For the
|
52 |
|
|
targets it could support, it worked well. It had limitations inherent
|
53 |
|
|
in its design that would be difficult to resolve, so a major effort
|
54 |
|
|
was made to resolve those limitations and gcc version 2 was the
|
55 |
|
|
result.
|
56 |
|
|
|
57 |
|
|
When we had gcc2 in a useful state, development efforts on gcc1
|
58 |
|
|
stopped and we all concentrated on making gcc2 better than gcc1 could
|
59 |
|
|
ever be. This is the kind of step forward we wanted to make with the
|
60 |
|
|
EGCS project when it was formed in 1997.
|
61 |
|
|
|
62 |
|
|
In April 1999 the Free Software Foundation officially halted
|
63 |
|
|
development on the gcc2 compiler and appointed the EGCS project as the
|
64 |
|
|
official GCC maintainers. The net result was a single project which
|
65 |
|
|
carries forward GCC development under the ultimate control of the
|
66 |
|
|
[32]GCC Steering Committee.
|
67 |
|
|
_________________________________________________________________
|
68 |
|
|
|
69 |
|
|
What is an open development model?
|
70 |
|
|
|
71 |
|
|
We are using a bazaar style [33][1] approach to GCC development: we
|
72 |
|
|
make snapshots publicly available to anyone who wants to try them; we
|
73 |
|
|
welcome anyone to join the development mailing list. All of the
|
74 |
|
|
discussions on the development mailing list are available via the web.
|
75 |
|
|
We're going to be making releases with a much higher frequency than
|
76 |
|
|
they have been made in the past.
|
77 |
|
|
|
78 |
|
|
In addition to weekly snapshots of the GCC development sources, we
|
79 |
|
|
have the sources readable from an SVN server by anyone. Furthermore we
|
80 |
|
|
are using SVN to allow maintainers write access to the sources.
|
81 |
|
|
|
82 |
|
|
There have been many potential GCC developers who were not able to
|
83 |
|
|
participate in GCC development in the past. We want these people to
|
84 |
|
|
help in any way they can; we ultimately want GCC to be the best
|
85 |
|
|
compiler in the world.
|
86 |
|
|
|
87 |
|
|
A compiler is a complicated piece of software, there will still be
|
88 |
|
|
strong central maintainers who will reject patches, who will demand
|
89 |
|
|
documentation of implementations, and who will keep the level of
|
90 |
|
|
quality as high as it is today. Code that could use wider testing may
|
91 |
|
|
be integrated--code that is simply ill-conceived won't be.
|
92 |
|
|
|
93 |
|
|
GCC is not the first piece of software to use this open development
|
94 |
|
|
process; FreeBSD, the Emacs lisp repository, and the Linux kernel are
|
95 |
|
|
a few examples of the bazaar style of development.
|
96 |
|
|
|
97 |
|
|
With GCC, we are adding new features and optimizations at a rate that
|
98 |
|
|
has not been done since the creation of gcc2; these additions
|
99 |
|
|
inevitably have a temporarily destabilizing effect. With the help of
|
100 |
|
|
developers working together with this bazaar style development, the
|
101 |
|
|
resulting stability and quality levels will be better than we've had
|
102 |
|
|
before.
|
103 |
|
|
|
104 |
|
|
[1] We've been discussing different development models a lot over
|
105 |
|
|
the past few months. The paper which started all of this introduced
|
106 |
|
|
two terms: A cathedral development model versus a bazaar
|
107 |
|
|
development model. The paper is written by Eric S. Raymond, it is
|
108 |
|
|
called ``The Cathedral and the Bazaar''. The paper is a useful
|
109 |
|
|
starting point for discussions.
|
110 |
|
|
_________________________________________________________________
|
111 |
|
|
|
112 |
|
|
How do I get a bug fixed or a feature added?
|
113 |
|
|
|
114 |
|
|
There are lots of ways to get something fixed. The list below may be
|
115 |
|
|
incomplete, but it covers many of the common cases. These are listed
|
116 |
|
|
roughly in order of decreasing difficulty for the average GCC user,
|
117 |
|
|
meaning someone who is not skilled in the internals of GCC, and where
|
118 |
|
|
difficulty is measured in terms of the time required to fix the bug.
|
119 |
|
|
No alternative is better than any other; each has its benefits and
|
120 |
|
|
disadvantages.
|
121 |
|
|
* Fix it yourself. This alternative will probably bring results, if
|
122 |
|
|
you work hard enough, but will probably take a lot of time, and,
|
123 |
|
|
depending on the quality of your work and the perceived benefits
|
124 |
|
|
of your changes, your code may or may not ever make it into an
|
125 |
|
|
official release of GCC.
|
126 |
|
|
* [34]Report the problem to the GCC bug tracking system and hope
|
127 |
|
|
that someone will be kind enough to fix it for you. While this is
|
128 |
|
|
certainly possible, and often happens, there is no guarantee that
|
129 |
|
|
it will. You should not expect the same response from this method
|
130 |
|
|
that you would see from a commercial support organization since
|
131 |
|
|
the people who read GCC bug reports, if they choose to help you,
|
132 |
|
|
will be volunteering their time.
|
133 |
|
|
* Hire someone to fix it for you. There are various companies and
|
134 |
|
|
individuals providing support for GCC. This alternative costs
|
135 |
|
|
money, but is relatively likely to get results.
|
136 |
|
|
_________________________________________________________________
|
137 |
|
|
|
138 |
|
|
Does GCC work on my platform?
|
139 |
|
|
|
140 |
|
|
The host/target specific installation notes for GCC include
|
141 |
|
|
information about known problems with installing or using GCC on
|
142 |
|
|
particular platforms. These are included in the sources for a release
|
143 |
|
|
in INSTALL/specific.html, and the [35]latest version is always
|
144 |
|
|
available at the GCC web site. Reports of [36]successful builds for
|
145 |
|
|
several versions of GCC are also available at the web site.
|
146 |
|
|
_________________________________________________________________
|
147 |
|
|
|
148 |
|
|
Installation
|
149 |
|
|
|
150 |
|
|
How to install multiple versions of GCC
|
151 |
|
|
|
152 |
|
|
It may be desirable to install multiple versions of the compiler on
|
153 |
|
|
the same system. This can be done by using different prefix paths at
|
154 |
|
|
configure time and a few symlinks.
|
155 |
|
|
|
156 |
|
|
Basically, configure the two compilers with different --prefix
|
157 |
|
|
options, then build and install each compiler. Assume you want "gcc"
|
158 |
|
|
to be the latest compiler and available in /usr/local/bin; also assume
|
159 |
|
|
that you want "gcc2" to be the older gcc2 compiler and also available
|
160 |
|
|
in /usr/local/bin.
|
161 |
|
|
|
162 |
|
|
The easiest way to do this is to configure the new GCC with
|
163 |
|
|
--prefix=/usr/local/gcc and the older gcc2 with
|
164 |
|
|
--prefix=/usr/local/gcc2. Build and install both compilers. Then make
|
165 |
|
|
a symlink from /usr/local/bin/gcc to /usr/local/gcc/bin/gcc and from
|
166 |
|
|
/usr/local/bin/gcc2 to /usr/local/gcc2/bin/gcc. Create similar links
|
167 |
|
|
for the "g++", "c++" and "g77" compiler drivers.
|
168 |
|
|
|
169 |
|
|
An alternative to using symlinks is to configure with a
|
170 |
|
|
--program-transform-name option. This option specifies a sed command
|
171 |
|
|
to process installed program names with. Using it you can, for
|
172 |
|
|
instance, have all the new GCC programs installed as "new-gcc" and the
|
173 |
|
|
like. You will still have to specify different --prefix options for
|
174 |
|
|
new GCC and old GCC, because it is only the executable program names
|
175 |
|
|
that are transformed. The difference is that you (as administrator) do
|
176 |
|
|
not have to set up symlinks, but must specify additional directories
|
177 |
|
|
in your (as a user) PATH. A complication with --program-transform-name
|
178 |
|
|
is that the sed command invariably contains characters significant to
|
179 |
|
|
the shell, and these have to be escaped correctly, also it is not
|
180 |
|
|
possible to use "^" or "$" in the command. Here is the option to
|
181 |
|
|
prefix "new-" to the new GCC installed programs:
|
182 |
|
|
|
183 |
|
|
--program-transform-name='s,\\\\(.*\\\\),new-\\\\1,'
|
184 |
|
|
|
185 |
|
|
With the above --prefix option, that will install the new GCC programs
|
186 |
|
|
into /usr/local/gcc/bin with names prefixed by "new-". You can use
|
187 |
|
|
--program-transform-name if you have multiple versions of GCC, and
|
188 |
|
|
wish to be sure about which version you are invoking.
|
189 |
|
|
|
190 |
|
|
If you use --prefix, GCC may have difficulty locating a GNU assembler
|
191 |
|
|
or linker on your system, [37]GCC can not find GNU as/GNU ld explains
|
192 |
|
|
how to deal with this.
|
193 |
|
|
|
194 |
|
|
Another option that may be easier is to use the --program-prefix= or
|
195 |
|
|
--program-suffix= options to configure. So if you're installing GCC
|
196 |
|
|
2.95.2 and don't want to disturb the current version of GCC in
|
197 |
|
|
/usr/local/bin/, you could do
|
198 |
|
|
|
199 |
|
|
configure --program-suffix=-2.95.2
|
200 |
|
|
|
201 |
|
|
This should result in GCC being installed as /usr/local/bin/gcc-2.95.2
|
202 |
|
|
instead of /usr/local/bin/gcc.
|
203 |
|
|
_________________________________________________________________
|
204 |
|
|
|
205 |
|
|
Dynamic linker is unable to find GCC libraries
|
206 |
|
|
|
207 |
|
|
This problem manifests itself by programs not finding shared libraries
|
208 |
|
|
they depend on when the programs are started. Note this problem often
|
209 |
|
|
manifests itself with failures in the libio/libstdc++ tests after
|
210 |
|
|
configuring with --enable-shared and building GCC.
|
211 |
|
|
|
212 |
|
|
GCC does not specify a runpath so that the dynamic linker can find
|
213 |
|
|
dynamic libraries at runtime.
|
214 |
|
|
|
215 |
|
|
The short explanation is that if you always pass a -R option to the
|
216 |
|
|
linker, then your programs become dependent on directories which may
|
217 |
|
|
be NFS mounted, and programs may hang unnecessarily when an NFS server
|
218 |
|
|
goes down.
|
219 |
|
|
|
220 |
|
|
The problem is not programs that do require the directories; those
|
221 |
|
|
programs are going to hang no matter what you do. The problem is
|
222 |
|
|
programs that do not require the directories.
|
223 |
|
|
|
224 |
|
|
SunOS effectively always passed a -R option for every -L option; this
|
225 |
|
|
was a bad idea, and so it was removed for Solaris. We should not
|
226 |
|
|
recreate it.
|
227 |
|
|
|
228 |
|
|
However, if you feel you really need such an option to be passed
|
229 |
|
|
automatically to the linker, you may add it to the GCC specs file.
|
230 |
|
|
This file can be found in the same directory that contains cc1 (run
|
231 |
|
|
gcc -print-prog-name=cc1 to find it). You may add linker flags such as
|
232 |
|
|
-R or -rpath, depending on platform and linker, to the *link or *lib
|
233 |
|
|
specs.
|
234 |
|
|
|
235 |
|
|
Another alternative is to install a wrapper script around gcc, g++ or
|
236 |
|
|
ld that adds the appropriate directory to the environment variable
|
237 |
|
|
LD_RUN_PATH or equivalent (again, it's platform-dependent).
|
238 |
|
|
|
239 |
|
|
Yet another option, that works on a few platforms, is to hard-code the
|
240 |
|
|
full pathname of the library into its soname. This can only be
|
241 |
|
|
accomplished by modifying the appropriate .ml file within
|
242 |
|
|
libstdc++/config (and also libg++/config, if you are building libg++),
|
243 |
|
|
so that $(libdir)/ appears just before the library name in -soname or
|
244 |
|
|
-h options.
|
245 |
|
|
_________________________________________________________________
|
246 |
|
|
|
247 |
|
|
GCC can not find GNU as/GNU ld
|
248 |
|
|
|
249 |
|
|
GCC searches the PATH for an assembler and a loader, but it only does
|
250 |
|
|
so after searching a directory list hard-coded in the GCC executables.
|
251 |
|
|
Since, on most platforms, the hard-coded list includes directories in
|
252 |
|
|
which the system assembler and loader can be found, you may have to
|
253 |
|
|
take one of the following actions to arrange that GCC uses the GNU
|
254 |
|
|
versions of those programs.
|
255 |
|
|
|
256 |
|
|
To ensure that GCC finds the GNU assembler (the GNU loader), which are
|
257 |
|
|
required by [38]some configurations, you should configure these with
|
258 |
|
|
the same --prefix option as you used for GCC. Then build & install GNU
|
259 |
|
|
as (GNU ld) and proceed with building GCC.
|
260 |
|
|
|
261 |
|
|
Another alternative is to create links to GNU as and ld in any of the
|
262 |
|
|
directories printed by the command `gcc -print-search-dirs | grep
|
263 |
|
|
'^programs:''. The link to `ld' should be named `real-ld' if `ld'
|
264 |
|
|
already exists. If such links do not exist while you're compiling GCC,
|
265 |
|
|
you may have to create them in the build directories too, within the
|
266 |
|
|
gcc directory and in all the gcc/stage* subdirectories.
|
267 |
|
|
|
268 |
|
|
GCC 2.95 allows you to specify the full pathname of the assembler and
|
269 |
|
|
the linker to use. The configure flags are `--with-as=/path/to/as' and
|
270 |
|
|
`--with-ld=/path/to/ld'. GCC will try to use these pathnames before
|
271 |
|
|
looking for `as' or `(real-)ld' in the standard search dirs. If, at
|
272 |
|
|
configure-time, the specified programs are found to be GNU utilities,
|
273 |
|
|
`--with-gnu-as' and `--with-gnu-ld' need not be used; these flags will
|
274 |
|
|
be auto-detected. One drawback of this option is that it won't allow
|
275 |
|
|
you to override the search path for assembler and linker with
|
276 |
|
|
command-line options -B/path/ if the specified filenames exist.
|
277 |
|
|
_________________________________________________________________
|
278 |
|
|
|
279 |
|
|
cpp: Usage:... Error
|
280 |
|
|
|
281 |
|
|
If you get an error like this when building GCC (particularly when
|
282 |
|
|
building __mulsi3), then you likely have a problem with your
|
283 |
|
|
environment variables.
|
284 |
|
|
cpp: Usage: /usr/lib/gcc-lib/i586-unknown-linux-gnulibc1/2.7.2.3/cpp
|
285 |
|
|
[switches] input output
|
286 |
|
|
|
287 |
|
|
First look for an explicit '.' in either LIBRARY_PATH or
|
288 |
|
|
GCC_EXEC_PREFIX from your environment. If you do not find an explicit
|
289 |
|
|
'.', look for an empty pathname in those variables. Note that ':' at
|
290 |
|
|
either the start or end of these variables is an implicit '.' and will
|
291 |
|
|
cause problems.
|
292 |
|
|
|
293 |
|
|
Also note '::' in these paths will also cause similar problems.
|
294 |
|
|
_________________________________________________________________
|
295 |
|
|
|
296 |
|
|
Optimizing the compiler itself
|
297 |
|
|
|
298 |
|
|
If you want to test a particular optimization option, it's useful to
|
299 |
|
|
try bootstrapping the compiler with that option turned on. For
|
300 |
|
|
example, to test the -fssa option, you could bootstrap like this:
|
301 |
|
|
make BOOT_CFLAGS="-O2 -fssa" bootstrap
|
302 |
|
|
_________________________________________________________________
|
303 |
|
|
|
304 |
|
|
Why does libiconv get linked into jc1 on Solaris?
|
305 |
|
|
|
306 |
|
|
The Java front end requires iconv. If the compiler used to bootstrap
|
307 |
|
|
GCC finds libiconv (because the GNU version of libiconv has been
|
308 |
|
|
installed in the same prefix as the bootstrap compiler), but the newly
|
309 |
|
|
built GCC does not find the library (because it will be installed with
|
310 |
|
|
a different prefix), then a link-time error will occur when building
|
311 |
|
|
jc1. This problem does not show up so often on platforms that have
|
312 |
|
|
libiconv in a default location (like /usr/lib) because then both
|
313 |
|
|
compilers can find a library named libiconv, even though it is a
|
314 |
|
|
different library.
|
315 |
|
|
|
316 |
|
|
Using --disable-nls at configure-time does not prevent this problem
|
317 |
|
|
because jc1 uses iconv even in that case. Solutions include
|
318 |
|
|
temporarily removing the GNU libiconv, copying it to a default
|
319 |
|
|
location such as /usr/lib/, and using --enable-languages at
|
320 |
|
|
configure-time to disable Java.
|
321 |
|
|
_________________________________________________________________
|
322 |
|
|
|
323 |
|
|
Testsuite problems
|
324 |
|
|
|
325 |
|
|
How do I pass flags like -fnew-abi to the testsuite?
|
326 |
|
|
|
327 |
|
|
If you invoke runtest directly, you can use the --tool_opts option,
|
328 |
|
|
e.g:
|
329 |
|
|
runtest --tool_opts "-fnew-abi -fno-honor-std"
|
330 |
|
|
|
331 |
|
|
Or, if you use make check you can use the make variable RUNTESTFLAGS,
|
332 |
|
|
e.g:
|
333 |
|
|
make RUNTESTFLAGS="--tool_opts '-fnew-abi -fno-honor-std'" check-g++
|
334 |
|
|
_________________________________________________________________
|
335 |
|
|
|
336 |
|
|
How can I run the test suite with multiple options?
|
337 |
|
|
|
338 |
|
|
If you invoke runtest directly, you can use the --target_board option,
|
339 |
|
|
e.g:
|
340 |
|
|
runtest --target_board "unix{-fPIC,-fpic,}"
|
341 |
|
|
|
342 |
|
|
Or, if you use make check you can use the make variable RUNTESTFLAGS,
|
343 |
|
|
e.g:
|
344 |
|
|
make RUNTESTFLAGS="--target_board 'unix{-fPIC,-fpic,}'" check-gcc
|
345 |
|
|
|
346 |
|
|
Either of these examples will run the tests three times. Once with
|
347 |
|
|
-fPIC, once with -fpic, and once with no additional flags.
|
348 |
|
|
|
349 |
|
|
This technique is particularly useful on multilibbed targets.
|
350 |
|
|
_________________________________________________________________
|
351 |
|
|
|
352 |
|
|
Older versions of GCC and EGCS
|
353 |
|
|
|
354 |
|
|
Is there a stringstream / sstream for GCC 2.95.2?
|
355 |
|
|
|
356 |
|
|
Yes, it's at:
|
357 |
|
|
[39]http://gcc.gnu.org/ml/libstdc++/2000-q2/msg00700/sstream.
|
358 |
|
|
_________________________________________________________________
|
359 |
|
|
|
360 |
|
|
Miscellaneous
|
361 |
|
|
|
362 |
|
|
Friend Templates
|
363 |
|
|
|
364 |
|
|
In order to make a specialization of a template function a friend of a
|
365 |
|
|
(possibly template) class, you must explicitly state that the friend
|
366 |
|
|
function is a template, by appending angle brackets to its name, and
|
367 |
|
|
this template function must have been declared already. Here's an
|
368 |
|
|
example:
|
369 |
|
|
template class foo {
|
370 |
|
|
friend void bar(foo);
|
371 |
|
|
}
|
372 |
|
|
|
373 |
|
|
The above declaration declares a non-template function named bar, so
|
374 |
|
|
it must be explicitly defined for each specialization of foo. A
|
375 |
|
|
template definition of bar won't do, because it is unrelated with the
|
376 |
|
|
non-template declaration above. So you'd have to end up writing:
|
377 |
|
|
void bar(foo) { /* ... */ }
|
378 |
|
|
void bar(foo) { /* ... */ }
|
379 |
|
|
|
380 |
|
|
If you meant bar to be a template function, you should have
|
381 |
|
|
forward-declared it as follows. Note that, since the template function
|
382 |
|
|
declaration refers to the template class, the template class must be
|
383 |
|
|
forward-declared too:
|
384 |
|
|
template
|
385 |
|
|
class foo;
|
386 |
|
|
|
387 |
|
|
template
|
388 |
|
|
void bar(foo);
|
389 |
|
|
|
390 |
|
|
template
|
391 |
|
|
class foo {
|
392 |
|
|
friend void bar<>(foo);
|
393 |
|
|
};
|
394 |
|
|
|
395 |
|
|
template
|
396 |
|
|
void bar(foo) { /* ... */ }
|
397 |
|
|
|
398 |
|
|
In this case, the template argument list could be left empty, because
|
399 |
|
|
it can be implicitly deduced from the function arguments, but the
|
400 |
|
|
angle brackets must be present, otherwise the declaration will be
|
401 |
|
|
taken as a non-template function. Furthermore, in some cases, you may
|
402 |
|
|
have to explicitly specify the template arguments, to remove
|
403 |
|
|
ambiguity.
|
404 |
|
|
|
405 |
|
|
An error in the last public comment draft of the ANSI/ISO C++ Standard
|
406 |
|
|
and the fact that previous releases of GCC would accept such friend
|
407 |
|
|
declarations as template declarations has led people to believe that
|
408 |
|
|
the forward declaration was not necessary, but, according to the final
|
409 |
|
|
version of the Standard, it is.
|
410 |
|
|
_________________________________________________________________
|
411 |
|
|
|
412 |
|
|
dynamic_cast, throw, typeid don't work with shared libraries
|
413 |
|
|
|
414 |
|
|
The new C++ ABI in the GCC 3.0 series uses address comparisons, rather
|
415 |
|
|
than string compares, to determine type equality. This leads to better
|
416 |
|
|
performance. Like other objects that have to be present in the final
|
417 |
|
|
executable, these std::type_info objects have what is called vague
|
418 |
|
|
linkage because they are not tightly bound to any one particular
|
419 |
|
|
translation unit (object file). The compiler has to emit them in any
|
420 |
|
|
translation unit that requires their presence, and then rely on the
|
421 |
|
|
linking and loading process to make sure that only one of them is
|
422 |
|
|
active in the final executable. With static linking all of these
|
423 |
|
|
symbols are resolved at link time, but with dynamic linking, further
|
424 |
|
|
resolution occurs at load time. You have to ensure that objects within
|
425 |
|
|
a shared library are resolved against objects in the executable and
|
426 |
|
|
other shared libraries.
|
427 |
|
|
* For a program which is linked against a shared library, no
|
428 |
|
|
additional precautions are needed.
|
429 |
|
|
* You cannot create a shared library with the "-Bsymbolic" option,
|
430 |
|
|
as that prevents the resolution described above.
|
431 |
|
|
* If you use dlopen to explicitly load code from a shared library,
|
432 |
|
|
you must do several things. First, export global symbols from the
|
433 |
|
|
executable by linking it with the "-E" flag (you will have to
|
434 |
|
|
specify this as "-Wl,-E" if you are invoking the linker in the
|
435 |
|
|
usual manner from the compiler driver, g++). You must also make
|
436 |
|
|
the external symbols in the loaded library available for
|
437 |
|
|
subsequent libraries by providing the RTLD_GLOBAL flag to dlopen.
|
438 |
|
|
The symbol resolution can be immediate or lazy.
|
439 |
|
|
|
440 |
|
|
Template instantiations are another, user visible, case of objects
|
441 |
|
|
with vague linkage, which needs similar resolution. If you do not take
|
442 |
|
|
the above precautions, you may discover that a template instantiation
|
443 |
|
|
with the same argument list, but instantiated in multiple translation
|
444 |
|
|
units, has several addresses, depending in which translation unit the
|
445 |
|
|
address is taken. (This is not an exhaustive list of the kind of
|
446 |
|
|
objects which have vague linkage and are expected to be resolved
|
447 |
|
|
during linking & loading.)
|
448 |
|
|
|
449 |
|
|
If you are worried about different objects with the same name
|
450 |
|
|
colliding during the linking or loading process, then you should use
|
451 |
|
|
namespaces to disambiguate them. Giving distinct objects with global
|
452 |
|
|
linkage the same name is a violation of the One Definition Rule (ODR)
|
453 |
|
|
[basic.def.odr].
|
454 |
|
|
|
455 |
|
|
For more details about the way that GCC implements these and other C++
|
456 |
|
|
features, please read the [40]ABI specification. Note the
|
457 |
|
|
std::type_info objects which must be resolved all begin with "_ZTS".
|
458 |
|
|
Refer to ld's documentation for a description of the "-E" &
|
459 |
|
|
"-Bsymbolic" flags.
|
460 |
|
|
_________________________________________________________________
|
461 |
|
|
|
462 |
|
|
Why do I need autoconf, bison, xgettext, automake, etc?
|
463 |
|
|
|
464 |
|
|
If you're using diffs up dated from one snapshot to the next, or if
|
465 |
|
|
you're using the SVN repository, you may need several additional
|
466 |
|
|
programs to build GCC.
|
467 |
|
|
|
468 |
|
|
These include, but are not necessarily limited to autoconf, automake,
|
469 |
|
|
bison, and xgettext.
|
470 |
|
|
|
471 |
|
|
This is necessary because neither diff nor cvs keep timestamps
|
472 |
|
|
correct. This causes problems for generated files as "make" may think
|
473 |
|
|
those generated files are out of date and try to regenerate them.
|
474 |
|
|
|
475 |
|
|
An easy way to work around this problem is to use the gcc_update
|
476 |
|
|
script in the contrib subdirectory of GCC, which handles this
|
477 |
|
|
transparently without requiring installation of any additional tools.
|
478 |
|
|
|
479 |
|
|
When building from diffs or SVN or if you modified some sources, you
|
480 |
|
|
may also need to obtain development versions of some GNU tools, as the
|
481 |
|
|
production versions do not necessarily handle all features needed to
|
482 |
|
|
rebuild GCC.
|
483 |
|
|
|
484 |
|
|
In general, the current versions of these tools from
|
485 |
|
|
[41]ftp://ftp.gnu.org/gnu/ will work. At present, Autoconf 2.50 is not
|
486 |
|
|
supported, and you will need to use Autoconf 2.13; work is in progress
|
487 |
|
|
to fix this problem. Also look at
|
488 |
|
|
[42]ftp://gcc.gnu.org/pub/gcc/infrastructure/ for any special versions
|
489 |
|
|
of packages.
|
490 |
|
|
_________________________________________________________________
|
491 |
|
|
|
492 |
|
|
Why can't I build a shared library?
|
493 |
|
|
|
494 |
|
|
When building a shared library you may get an error message from the
|
495 |
|
|
linker like `assert pure-text failed:' or `DP relative code in file'.
|
496 |
|
|
|
497 |
|
|
This kind of error occurs when you've failed to provide proper flags
|
498 |
|
|
to gcc when linking the shared library.
|
499 |
|
|
|
500 |
|
|
You can get this error even if all the .o files for the shared library
|
501 |
|
|
were compiled with the proper PIC option. When building a shared
|
502 |
|
|
library, gcc will compile additional code to be included in the
|
503 |
|
|
library. That additional code must also be compiled with the proper
|
504 |
|
|
PIC option.
|
505 |
|
|
|
506 |
|
|
Adding the proper PIC option (-fpic or -fPIC) to the link line which
|
507 |
|
|
creates the shared library will fix this problem on targets that
|
508 |
|
|
support PIC in this manner. For example:
|
509 |
|
|
gcc -c -fPIC myfile.c
|
510 |
|
|
gcc -shared -o libmyfile.so -fPIC myfile.o
|
511 |
|
|
_________________________________________________________________
|
512 |
|
|
|
513 |
|
|
When building C++, the linker says my constructors, destructors or virtual
|
514 |
|
|
tables are undefined, but I defined them
|
515 |
|
|
|
516 |
|
|
The ISO C++ Standard specifies that all virtual methods of a class
|
517 |
|
|
that are not pure-virtual must be defined, but does not require any
|
518 |
|
|
diagnostic for violations of this rule [class.virtual]/8. Based on
|
519 |
|
|
this assumption, GCC will only emit the implicitly defined
|
520 |
|
|
constructors, the assignment operator, the destructor and the virtual
|
521 |
|
|
table of a class in the translation unit that defines its first such
|
522 |
|
|
non-inline method.
|
523 |
|
|
|
524 |
|
|
Therefore, if you fail to define this particular method, the linker
|
525 |
|
|
may complain about the lack of definitions for apparently unrelated
|
526 |
|
|
symbols. Unfortunately, in order to improve this error message, it
|
527 |
|
|
might be necessary to change the linker, and this can't always be
|
528 |
|
|
done.
|
529 |
|
|
|
530 |
|
|
The solution is to ensure that all virtual methods that are not pure
|
531 |
|
|
are defined. Note that a destructor must be defined even if it is
|
532 |
|
|
declared pure-virtual [class.dtor]/7.
|
533 |
|
|
_________________________________________________________________
|
534 |
|
|
|
535 |
|
|
Will GCC someday include an incremental linker?
|
536 |
|
|
|
537 |
|
|
Incremental linking is part of the linker, not the compiler. As such,
|
538 |
|
|
GCC doesn't have anything to do with incremental linking. Depending on
|
539 |
|
|
what platform you use, it may be possible to tell GCC to use the
|
540 |
|
|
platform's native linker (e.g., Solaris' ild(1)).
|
541 |
|
|
|
542 |
|
|
References
|
543 |
|
|
|
544 |
|
|
1. http://gcc.gnu.org/faq.html
|
545 |
|
|
2. http://c-faq.com/
|
546 |
|
|
3. http://www.jamesd.demon.co.uk/csc/faq.html
|
547 |
|
|
4. http://www.fortran.com/fortran/info.html
|
548 |
|
|
5. http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html
|
549 |
|
|
6. http://gcc.gnu.org/java/faq.html
|
550 |
|
|
7. http://gcc.gnu.org/faq.html#general
|
551 |
|
|
8. http://gcc.gnu.org/faq.html#gcc
|
552 |
|
|
9. http://gcc.gnu.org/faq.html#open-development
|
553 |
|
|
10. http://gcc.gnu.org/faq.html#support
|
554 |
|
|
11. http://gcc.gnu.org/faq.html#platforms
|
555 |
|
|
12. http://gcc.gnu.org/faq.html#installation
|
556 |
|
|
13. http://gcc.gnu.org/faq.html#multiple
|
557 |
|
|
14. http://gcc.gnu.org/faq.html#rpath
|
558 |
|
|
15. http://gcc.gnu.org/faq.html#rpath
|
559 |
|
|
16. http://gcc.gnu.org/faq.html#gas
|
560 |
|
|
17. http://gcc.gnu.org/faq.html#environ
|
561 |
|
|
18. http://gcc.gnu.org/faq.html#optimizing
|
562 |
|
|
19. http://gcc.gnu.org/faq.html#iconv
|
563 |
|
|
20. http://gcc.gnu.org/faq.html#testsuite
|
564 |
|
|
21. http://gcc.gnu.org/faq.html#testoptions
|
565 |
|
|
22. http://gcc.gnu.org/faq.html#multipletests
|
566 |
|
|
23. http://gcc.gnu.org/faq.html#old
|
567 |
|
|
24. http://gcc.gnu.org/faq.html#2.95sstream
|
568 |
|
|
25. http://gcc.gnu.org/faq.html#misc
|
569 |
|
|
26. http://gcc.gnu.org/faq.html#friend
|
570 |
|
|
27. http://gcc.gnu.org/faq.html#dso
|
571 |
|
|
28. http://gcc.gnu.org/faq.html#generated_files
|
572 |
|
|
29. http://gcc.gnu.org/faq.html#picflag-needed
|
573 |
|
|
30. http://gcc.gnu.org/faq.html#vtables
|
574 |
|
|
31. http://gcc.gnu.org/faq.html#incremental
|
575 |
|
|
32. http://gcc.gnu.org/steering.html
|
576 |
|
|
33. http://gcc.gnu.org/faq.html#cathedral-vs-bazaar
|
577 |
|
|
34. http://gcc.gnu.org/bugs.html
|
578 |
|
|
35. http://gcc.gnu.org/install/specific.html
|
579 |
|
|
36. http://gcc.gnu.org/buildstat.html
|
580 |
|
|
37. http://gcc.gnu.org/faq.html#gas
|
581 |
|
|
38. http://gcc.gnu.org/install/specific.html
|
582 |
|
|
39. http://gcc.gnu.org/ml/libstdc++/2000-q2/msg00700/sstream
|
583 |
|
|
40. http://www.codesourcery.com/cxx-abi/
|
584 |
|
|
41. ftp://ftp.gnu.org/gnu/
|
585 |
|
|
42. ftp://gcc.gnu.org/pub/gcc/infrastructure/
|