| <html> |
| |
| <head> |
| <title>GCC Frequently Asked Questions</title> |
| </head> |
| |
| <body> |
| |
| <h1>GCC Frequently Asked Questions</h1> |
| |
| <p>The latest version of this document is always available at |
| <a href="http://gcc.gnu.org/faq.html">http://gcc.gnu.org/faq.html</a>.</p> |
| |
| <p>This FAQ tries to answer specific questions concerning GCC. For |
| general information regarding C, C++, resp. Fortran please check the |
| <a href="http://c-faq.com/">comp.lang.c FAQ</a>, |
| <a href="http://www.comeaucomputing.com/csc/faq.html">comp.std.c++ |
| FAQ</a>, |
| and the <a href="http://www.fortran.com/fortran/info.html">Fortran |
| Information page</a>.</p> |
| |
| <p>Other GCC-related FAQs: |
| <a href="http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html"> |
| libstdc++-v3</a>, and |
| <a href="http://gcc.gnu.org/java/faq.html">GCJ</a>.</p> |
| |
| <hr /> |
| <h1>Questions</h1> |
| <ol> |
| <li><a href="#general">General information</a> |
| <ol> |
| <li><a href="#open-development">What is an open development model?</a></li> |
| <li><a href="#support">How do I get a bug fixed or a feature added?</a></li> |
| <li><a href="#platforms">Does GCC work on my platform?</a></li> |
| </ol></li> |
| |
| <li><a href="#installation">Installation</a> |
| <ol> |
| <li><a href="#multiple">How to install multiple versions of GCC</a></li> |
| <li><a href="#rpath">Dynamic linker is unable to find GCC libraries</a></li> |
| <li><a href="#rpath">libstdc++/libio tests fail badly with --enable-shared</a></li> |
| <li><a href="#gas">GCC can not find GNU as/GNU ld</a></li> |
| <li><a href="#environ">cpp: Usage:... Error</a></li> |
| <li><a href="#optimizing">Optimizing the compiler itself</a></li> |
| <li><a href="#iconv">Why does <code>libiconv</code> get linked into <code>jc1</code> on Solaris?</a></li> |
| </ol></li> |
| |
| <li><a href="#testsuite">Testsuite problems</a> |
| <ol> |
| <li><a href="#testoptions">How do I pass flags like |
| <code>-fnew-abi</code> to the testsuite?</a></li> |
| <li><a href="#multipletests">How can I run the test suite with multiple options?</a></li> |
| </ol></li> |
| |
| <li><a href="#misc">Miscellaneous</a> |
| <ol> |
| <li><a href="#friend">Friend Templates</a></li> |
| <li><a href="#dso"><code>dynamic_cast</code>, <code>throw</code>, <code>typeid</code> don't work with shared libraries</a></li> |
| <li><a href="#generated_files">Why do I need autoconf, bison, xgettext, automake, etc?</a></li> |
| <li><a href="#picflag-needed">Why can't I build a shared library?</a></li> |
| <li><a href="#vtables">When building C++, the linker says my constructors, destructors or virtual tables are undefined, but I defined them</a></li> |
| <li><a href="#incremental">Will GCC someday include an incremental linker?</a></li> |
| </ol></li> |
| </ol> |
| |
| |
| <hr /> |
| <a name="general"></a> |
| <h1>General information</h1> |
| |
| <h2><a name="open-development">What is an open development model?</a></h2> |
| |
| <p>We are using a bazaar style |
| <a href="#cathedral-vs-bazaar"><b>[1]</b></a> |
| approach to GCC development: we make snapshots publicly available to |
| anyone who wants to try them; we welcome anyone to join |
| the development mailing list. All of the discussions on the |
| development mailing list are available via the web. We're going to be |
| making releases with a much higher frequency than they have been made |
| in the past.</p> |
| |
| <p>In addition to weekly snapshots of the GCC development sources, we |
| have the sources readable from an SVN server by anyone. Furthermore we |
| are using SVN to allow maintainers write access to the sources.</p> |
| |
| <p>There have been many potential GCC developers who were not able to |
| participate in GCC development in the past. We want these people to |
| help in any way they can; we ultimately want GCC to be the best compiler |
| in the world.</p> |
| |
| <p>A compiler is a complicated piece of software, there will still be |
| strong central maintainers who will reject patches, who will demand |
| documentation of implementations, and who will keep the level of |
| quality as high as it is today. Code that could use wider testing may |
| be integrated--code that is simply ill-conceived won't be.</p> |
| |
| <p>GCC is not the first piece of software to use this open development |
| process; FreeBSD, the Emacs lisp repository, and the Linux kernel are |
| a few examples of the bazaar style of development.</p> |
| |
| <p>With GCC, we are adding new features and optimizations at a |
| rate that has not been done since the creation of gcc2; these |
| additions inevitably have a temporarily destabilizing effect. |
| With the help of developers working together with this bazaar style |
| development, the resulting stability and quality levels will be better |
| than we've had before.</p> |
| |
| <blockquote> |
| <a name="cathedral-vs-bazaar"><b>[1]</b></a> |
| We've been discussing different development models a lot over the |
| past few months. The paper which started all of this introduced two |
| terms: A <b>cathedral</b> development model versus a <b>bazaar</b> |
| development model. The paper is written by Eric S. Raymond, it is |
| called ``The Cathedral and the Bazaar''. |
| The paper is a useful starting point for discussions. |
| </blockquote> |
| |
| <hr /> |
| <!-- The "bugreport" anchor was used in ICE messages of GCC < 2.95.3. --> |
| <h2 id="bugreport"><a name="support">How do I get a bug fixed or |
| a feature added?</a></h2> |
| |
| <p>There are lots of ways to get something fixed. The list below may be |
| incomplete, but it covers many of the common cases. These are listed |
| roughly in order of decreasing difficulty for the average GCC user, |
| meaning someone who is not skilled in the internals of GCC, and where |
| difficulty is measured in terms of the time required to fix the bug. |
| No alternative is better than any other; each has its benefits and |
| disadvantages.</p> |
| |
| <ul> |
| <li>Fix it yourself. This alternative will probably bring results, |
| if you work hard enough, but will probably take a lot of time, |
| and, depending on the quality of your work and the perceived |
| benefits of your changes, your code may or may not ever make it |
| into an official release of GCC.</li> |
| |
| <li><a href="bugs.html">Report the problem to the GCC bug tracking system</a> |
| and hope that someone will be kind |
| enough to fix it for you. While this is certainly possible, and |
| often happens, there is no guarantee that it will. You should |
| not expect the same response from this method that you would see |
| from a commercial support organization since the people who read |
| GCC bug reports, if they choose to help you, will be volunteering their |
| time.</li> |
| |
| <li>Hire someone to fix it for you. There are various companies and |
| individuals providing support for GCC. This alternative costs |
| money, but is relatively likely to get results.</li> |
| </ul> |
| |
| <hr /> |
| <h2><a name="platforms">Does GCC work on my platform?</a></h2> |
| |
| <p>The host/target specific installation notes for GCC include information |
| about known problems with installing or using GCC on particular platforms. |
| These are included in the sources for a release in INSTALL/specific.html, |
| and the <a href="http://gcc.gnu.org/install/specific.html">latest version</a> |
| is always available at the GCC web site. |
| Reports of <a href="http://gcc.gnu.org/buildstat.html">successful builds</a> |
| for several versions of GCC are also available at the web site.</p> |
| |
| <hr /> |
| <a name="installation"></a> |
| <h1>Installation</h1> |
| |
| <h2><a name="multiple">How to install multiple versions of GCC</a></h2> |
| |
| <p>It may be desirable to install multiple versions of the compiler on |
| the same system. This can be done by using different prefix paths at |
| configure time and a few symlinks.</p> |
| |
| <p>Basically, configure the two compilers with different --prefix options, |
| then build and install each compiler. Assume you want "gcc" to be the latest |
| compiler and available in /usr/local/bin; also assume that you want "gcc2" |
| to be the older gcc2 compiler and also available in /usr/local/bin.</p> |
| |
| <p>The easiest way to do this is to configure the new GCC with |
| <code>--prefix=/usr/local/gcc</code> and the older gcc2 with |
| <code>--prefix=/usr/local/gcc2</code>. Build and install both |
| compilers. Then make a symlink from <code>/usr/local/bin/gcc</code> |
| to <code>/usr/local/gcc/bin/gcc</code> and from |
| <code>/usr/local/bin/gcc2</code> to |
| <code>/usr/local/gcc2/bin/gcc</code>. Create similar links for the |
| "g++", "c++" and "g77" compiler drivers.</p> |
| |
| <p>An alternative to using symlinks is to configure with a |
| <code>--program-transform-name</code> option. This option specifies a |
| sed command to process installed program names with. Using it you can, |
| for instance, have all the new GCC programs installed as "new-gcc" and |
| the like. You will still have to specify different |
| <code>--prefix</code> options for new GCC and old GCC, because it is |
| only the executable program names that are transformed. The difference |
| is that you (as administrator) do not have to set up symlinks, but |
| must specify additional directories in your (as a user) PATH. A |
| complication with <code>--program-transform-name</code> is that the |
| sed command invariably contains characters significant to the shell, |
| and these have to be escaped correctly, also it is not possible to use |
| "^" or "$" in the command. Here is the option to prefix "new-" to the |
| new GCC installed programs:</p> |
| <blockquote><code> |
| --program-transform-name='s,\\\\(.*\\\\),new-\\\\1,' |
| </code></blockquote> |
| <p>With the above <code>--prefix</code> option, that will install the new |
| GCC programs into <code>/usr/local/gcc/bin</code> with names prefixed |
| by "new-". You can use <code>--program-transform-name</code> if you |
| have multiple versions of GCC, and wish to be sure about which version |
| you are invoking.</p> |
| |
| <p>If you use <code>--prefix</code>, GCC may have difficulty locating a GNU |
| assembler or linker on your system, <a href="#gas">GCC can not find GNU |
| as/GNU ld</a> explains how to deal with this.</p> |
| |
| <p>Another option that may be easier is to use the |
| <code>--program-prefix=</code> or <code>--program-suffix=</code> |
| options to configure. So if you're installing GCC 2.95.2 and don't |
| want to disturb the current version of GCC in |
| <code>/usr/local/bin/</code>, you could do</p> |
| <blockquote><code> |
| configure --program-suffix=-2.95.2 <other configure options> |
| </code></blockquote> |
| <p>This should result in GCC being installed as |
| <code>/usr/local/bin/gcc-2.95.2</code> instead of |
| <code>/usr/local/bin/gcc</code>.</p> |
| |
| <hr /> |
| <h2><a name="rpath">Dynamic linker is unable to find GCC libraries</a></h2> |
| |
| <p>This problem manifests itself by programs not finding shared |
| libraries they depend on when the programs are started. Note this |
| problem often manifests itself with failures in the libio/libstdc++ |
| tests after configuring with <code>--enable-shared</code> and building GCC.</p> |
| |
| <p>GCC does not specify a runpath so that the dynamic linker can find |
| dynamic libraries at runtime.</p> |
| |
| <p>The short explanation is that if you always pass a -R option to the |
| linker, then your programs become dependent on directories which |
| may be NFS mounted, and programs may hang unnecessarily when an |
| NFS server goes down.</p> |
| |
| <p>The problem is not programs that do require the directories; those |
| programs are going to hang no matter what you do. The problem is |
| programs that do not require the directories.</p> |
| |
| <p>SunOS effectively always passed a <code>-R</code> option for every |
| <code>-L</code> option; this was a bad idea, and so it was removed for |
| Solaris. We should not recreate it.</p> |
| |
| <p>However, if you feel you really need such an option to be passed |
| automatically to the linker, you may add it to the GCC specs file. |
| This file can be found in the same directory that contains cc1 (run |
| <code>gcc -print-prog-name=cc1</code> to find it). You may add linker |
| flags such as <code>-R</code> or <code>-rpath</code>, depending on |
| platform and linker, to the <code>*link</code> or <code>*lib</code> |
| specs.</p> |
| |
| <p>Another alternative is to install a wrapper script around gcc, g++ |
| or ld that adds the appropriate directory to the environment variable |
| <code>LD_RUN_PATH</code> or equivalent (again, it's |
| platform-dependent).</p> |
| |
| <p>Yet another option, that works on a few platforms, is to hard-code |
| the full pathname of the library into its soname. This can only be |
| accomplished by modifying the appropriate <tt>.ml</tt> file within |
| <tt>libstdc++/config</tt> (and also <tt>libg++/config</tt>, if you are |
| building libg++), so that <code>$(libdir)/</code> appears just before |
| the library name in <code>-soname</code> or <code>-h</code> options.</p> |
| |
| <hr /> |
| <h2><a name="gas">GCC can not find GNU as/GNU ld</a></h2> |
| <p>GCC searches the PATH for an assembler and a loader, but it only |
| does so after searching a directory list hard-coded in the GCC |
| executables. Since, on most platforms, the hard-coded list includes |
| directories in which the system assembler and loader can be found, you |
| may have to take one of the following actions to arrange that GCC uses |
| the GNU versions of those programs.</p> |
| |
| <p>To ensure that GCC finds the GNU assembler (the GNU loader), which |
| are required by <a href="http://gcc.gnu.org/install/specific.html">some |
| configurations</a>, |
| you should configure these with the same --prefix option as you used |
| for GCC. Then build & install GNU as (GNU ld) and proceed with |
| building GCC.</p> |
| |
| <p>Another alternative is to create links to GNU as and ld in any of |
| the directories printed by the command `<tt>gcc -print-search-dirs | |
| grep '^programs:'</tt>'. The link to `<tt>ld</tt>' should be named |
| `<tt>real-ld</tt>' if `<tt>ld</tt>' already exists. If such links do |
| not exist while you're compiling GCC, you may have to create them in |
| the build directories too, within the <tt>gcc</tt> directory |
| <em>and</em> in all the <tt>gcc/stage*</tt> subdirectories.</p> |
| |
| <p>GCC 2.95 allows you to specify the full pathname of the assembler |
| and the linker to use. The configure flags are |
| `<tt>--with-as=/path/to/as</tt>' and `<tt>--with-ld=/path/to/ld</tt>'. |
| GCC will try to use these pathnames before looking for `<tt>as</tt>' |
| or `<tt>(real-)ld</tt>' in the standard search dirs. If, at |
| configure-time, the specified programs are found to be GNU utilities, |
| `<tt>--with-gnu-as</tt>' and `<tt>--with-gnu-ld</tt>' need not be |
| used; these flags will be auto-detected. One drawback of this option |
| is that it won't allow you to override the search path for assembler |
| and linker with command-line options <tt>-B/path/</tt> if the |
| specified filenames exist.</p> |
| |
| <hr /> |
| <h2><a name="environ">cpp: Usage:... Error</a></h2> |
| |
| <p>If you get an error like this when building GCC (particularly when building |
| __mulsi3), then you likely have a problem with your environment variables.</p> |
| <pre> |
| cpp: Usage: /usr/lib/gcc-lib/i586-unknown-linux-gnulibc1/2.7.2.3/cpp |
| [switches] input output |
| </pre> |
| <p>First look for an explicit '.' in either LIBRARY_PATH or GCC_EXEC_PREFIX |
| from your environment. If you do not find an explicit '.', look for |
| an empty pathname in those variables. Note that ':' at either the start |
| or end of these variables is an implicit '.' and will cause problems.</p> |
| |
| <p>Also note '::' in these paths will also cause similar problems.</p> |
| |
| |
| <hr /> |
| <h2><a name="optimizing">Optimizing the compiler itself</a></h2> |
| |
| <p>If you want to test a particular optimization option, it's useful to try |
| bootstrapping the compiler with that option turned on. For example, to |
| test the <code>-fssa</code> option, you could bootstrap like this:</p> |
| |
| <pre>make BOOT_CFLAGS="-O2 -fssa" bootstrap</pre> |
| |
| <hr /> |
| <h2><a name="iconv">Why does <code>libiconv</code> get linked into <code>jc1</code> on Solaris?</a></h2> |
| |
| <p>The Java front end requires <code>iconv</code>. If the compiler |
| used to bootstrap GCC finds <code>libiconv</code> (because the GNU |
| version of <code>libiconv</code> has been installed in the same prefix |
| as the bootstrap compiler), but the newly built GCC does not find the |
| library (because it will be installed with a different prefix), then a |
| link-time error will occur when building <code>jc1</code>. This |
| problem does not show up so often on platforms that have |
| <code>libiconv</code> in a default location (like |
| <code>/usr/lib</code>) because then both compilers can find a library |
| named <code>libiconv</code>, even though it is a different |
| library.</p> |
| |
| <p>Using <code>--disable-nls</code> at configure-time does not |
| prevent this problem because <code>jc1</code> uses |
| <code>iconv</code> even in that case. Solutions include temporarily |
| removing the GNU <code>libiconv</code>, copying it to a default |
| location such as <code>/usr/lib/</code>, and using |
| <code>--enable-languages</code> at configure-time to disable Java.</p> |
| |
| <hr /> |
| <a name="testsuite"></a> |
| <h1>Testsuite problems</h1> |
| |
| <h2><a name="testoptions">How do I pass flags like |
| <code>-fnew-abi</code> to the testsuite?</a></h2> |
| |
| <p>If you invoke <code>runtest</code> directly, you can use the |
| <code>--tool_opts</code> option, e.g:</p> |
| <pre> |
| runtest --tool_opts "-fnew-abi -fno-honor-std" <other options> |
| </pre> |
| <p>Or, if you use <code>make check</code> you can use the |
| <code>make</code> variable <code>RUNTESTFLAGS</code>, e.g:</p> |
| <pre> |
| make RUNTESTFLAGS="--tool_opts '-fnew-abi -fno-honor-std'" check-g++ |
| </pre> |
| |
| <hr /> |
| <h2><a name="multipletests"> How can I run the test suite with multiple options? </a></h2> |
| |
| <p>If you invoke <code>runtest</code> directly, you can use the |
| <code>--target_board</code> option, e.g:</p> |
| <pre> |
| runtest --target_board "unix{-fPIC,-fpic,}" <other options> |
| </pre> |
| <p>Or, if you use <code>make check</code> you can use the |
| <code>make</code> variable <code>RUNTESTFLAGS</code>, e.g:</p> |
| <pre> |
| make RUNTESTFLAGS="--target_board 'unix{-fPIC,-fpic,}'" check-gcc |
| </pre> |
| <p>Either of these examples will run the tests three times. Once |
| with <code>-fPIC</code>, once with <code>-fpic</code>, and once with |
| no additional flags.</p> |
| |
| <p>This technique is particularly useful on multilibbed targets.</p> |
| |
| |
| <hr /> |
| <a name="misc"></a> |
| <h1>Miscellaneous</h1> |
| |
| |
| <h2><a name="friend">Friend Templates</a></h2> |
| |
| <p>In order to make a specialization of a template function a friend |
| of a (possibly template) class, you must explicitly state that the |
| friend function is a template, by appending angle brackets to its |
| name, and this template function must have been declared already. |
| Here's an example:</p> |
| <pre> |
| template <typename T> class foo { |
| friend void bar(foo<T>); |
| } |
| </pre> |
| <p>The above declaration declares a non-template function named |
| <code>bar</code>, so it must be explicitly defined for <b>each</b> |
| specialization of <code>foo</code>. A template definition of <code>bar</code> |
| won't do, because it is unrelated with the non-template declaration |
| above. So you'd have to end up writing:</p> |
| <pre> |
| void bar(foo<int>) { /* ... */ } |
| void bar(foo<void>) { /* ... */ } |
| </pre> |
| <p>If you meant <code>bar</code> to be a template function, you should |
| have forward-declared it as follows. Note that, since the template |
| function declaration refers to the template class, the template class |
| must be forward-declared too:</p> |
| <pre> |
| template <typename T> |
| class foo; |
| |
| template <typename T> |
| void bar(foo<T>); |
| |
| template <typename T> |
| class foo { |
| friend void bar<>(foo<T>); |
| }; |
| |
| template <typename T> |
| void bar(foo<T>) { /* ... */ } |
| </pre> |
| <p>In this case, the template argument list could be left empty, |
| because it can be implicitly deduced from the function arguments, but |
| the angle brackets must be present, otherwise the declaration will be |
| taken as a non-template function. Furthermore, in some cases, you may |
| have to explicitly specify the template arguments, to remove |
| ambiguity.</p> |
| |
| <p>An error in the last public comment draft of the ANSI/ISO C++ |
| Standard and the fact that previous releases of GCC would accept such |
| friend declarations as template declarations has led people to believe |
| that the forward declaration was not necessary, but, according to the |
| final version of the Standard, it is.</p> |
| |
| |
| <hr /> |
| <h2><a name="dso"><code>dynamic_cast</code>, <code>throw</code>, <code>typeid</code> don't work with shared libraries</a></h2> |
| |
| <p>The new C++ ABI in the GCC 3.0 series uses address comparisons, |
| rather than string compares, to determine type equality. This leads |
| to better performance. Like other objects that have to be present in the |
| final executable, these <code>std::type_info</code> objects have what |
| is called vague linkage because they are not tightly bound to any one |
| particular translation unit (object file). The compiler has to emit |
| them in any translation unit that requires their presence, and then |
| rely on the linking and loading process to make sure that only one of |
| them is active in the final executable. With static linking all of |
| these symbols are resolved at link time, but with dynamic linking, |
| further resolution occurs at load time. You have to ensure that |
| objects within a shared library are resolved against objects in the |
| executable and other shared libraries.</p> |
| |
| <ul> |
| <li>For a program which is linked against a shared library, no additional |
| precautions are needed.</li> |
| |
| <li>You cannot create a shared library with the "<code>-Bsymbolic</code>" |
| option, as that prevents the resolution described above.</li> |
| |
| <li>If you use <code>dlopen</code> to explicitly load code from a shared |
| library, you must do several things. First, export global symbols from |
| the executable by linking it with the "<code>-E</code>" flag (you will |
| have to specify this as "<code>-Wl,-E</code>" if you are invoking |
| the linker in the usual manner from the compiler driver, <code>g++</code>). |
| You must also make the external symbols in the loaded library |
| available for subsequent libraries by providing the <code>RTLD_GLOBAL</code> |
| flag to <code>dlopen</code>. The symbol resolution can be immediate or |
| lazy.</li> |
| |
| </ul> |
| |
| <p>Template instantiations are another, user visible, case of objects |
| with vague linkage, which needs similar resolution. If you do not take |
| the above precautions, you may discover that a template instantiation |
| with the same argument list, but instantiated in multiple translation |
| units, has several addresses, depending in which translation unit the |
| address is taken. (This is <em>not</em> an exhaustive list of the kind |
| of objects which have vague linkage and are expected to be resolved |
| during linking & loading.)</p> |
| |
| <p>If you are worried about different objects with the same name |
| colliding during the linking or loading process, then you should use |
| namespaces to disambiguate them. Giving distinct objects with global |
| linkage the same name is a violation of the One Definition Rule (ODR) |
| [basic.def.odr].</p> |
| |
| <p>For more details about the way that GCC implements these and other |
| C++ features, please read the <a |
| href="http://www.codesourcery.com/cxx-abi/">ABI specification</a>. |
| Note the <code>std::type_info</code> objects which <i>must</i> be |
| resolved all begin with "_ZTS". Refer to <code>ld</code>'s |
| documentation for a description of the "<code>-E</code>" & |
| "<code>-Bsymbolic</code>" flags.</p> |
| |
| <hr /> |
| <h2><a name="generated_files">Why do I need autoconf, bison, xgettext, automake, etc?</a></h2> |
| |
| <p>If you're using diffs up dated from one snapshot to the next, or |
| if you're using the SVN repository, you may need several additional programs |
| to build GCC.</p> |
| |
| <p>These include, but are not necessarily limited to autoconf, automake, |
| bison, and xgettext.</p> |
| |
| <p>This is necessary because neither diff nor cvs keep timestamps |
| correct. This causes problems for generated files as "make" may think |
| those generated files are out of date and try to regenerate them.</p> |
| |
| <p>An easy way to work around this problem is to use the <code>gcc_update |
| </code> script in the contrib subdirectory of GCC, which handles this |
| transparently without requiring installation of any additional tools.</p> |
| |
| |
| <p>When building from diffs or SVN or if you modified some sources, |
| you may also need to obtain development versions of some GNU tools, as |
| the production versions do not necessarily handle all features needed |
| to rebuild GCC.</p> |
| |
| <p>In general, the current versions of these tools from <a |
| href="ftp://ftp.gnu.org/gnu/">ftp://ftp.gnu.org/gnu/</a> will work. |
| At present, Autoconf 2.50 is not supported, and you will need to use |
| Autoconf 2.13; work is in progress to fix this problem. Also look at |
| <a href="ftp://gcc.gnu.org/pub/gcc/infrastructure/"> |
| ftp://gcc.gnu.org/pub/gcc/infrastructure/</a> for any special versions |
| of packages.</p> |
| |
| |
| <hr /> |
| <h2><a name="picflag-needed">Why can't I build a shared library?</a></h2> |
| |
| <p>When building a shared library you may get an error message from the |
| linker like `assert pure-text failed:' or `DP relative code in file'.</p> |
| |
| <p>This kind of error occurs when you've failed to provide proper flags |
| to gcc when linking the shared library. </p> |
| |
| <p>You can get this error even if all the .o files for the shared library were |
| compiled with the proper PIC option. When building a shared library, gcc will |
| compile additional code to be included in the library. That additional code |
| must also be compiled with the proper PIC option.</p> |
| |
| <p>Adding the proper PIC option (<tt>-fpic</tt> or <tt>-fPIC</tt>) to the link |
| line which creates the shared library will fix this problem on targets that |
| support PIC in this manner. For example:</p> |
| <pre> |
| gcc -c -fPIC myfile.c |
| gcc -shared -o libmyfile.so -fPIC myfile.o |
| </pre> |
| |
| |
| <hr /> |
| <h2><a name="vtables">When building C++, the linker says my constructors, destructors or virtual tables are undefined, but I defined them</a></h2> |
| |
| <p>The ISO C++ Standard specifies that all virtual methods of a class |
| that are not pure-virtual must be defined, but does not require any |
| diagnostic for violations of this rule [class.virtual]/8. Based on |
| this assumption, GCC will only emit the implicitly defined |
| constructors, the assignment operator, the destructor and the virtual |
| table of a class in the translation unit that defines its first such |
| non-inline method.</p> |
| |
| <p>Therefore, if you fail to define this particular method, the linker |
| may complain about the lack of definitions for apparently unrelated |
| symbols. Unfortunately, in order to improve this error message, it |
| might be necessary to change the linker, and this can't always be |
| done.</p> |
| |
| <p>The solution is to ensure that all virtual methods that are not |
| pure are defined. Note that a destructor must be defined even if it |
| is declared pure-virtual [class.dtor]/7.</p> |
| |
| |
| <hr /> |
| <h2><a name="incremental">Will GCC someday include an incremental linker?</a></h2> |
| |
| <p>Incremental linking is part of the linker, not the compiler. As |
| such, GCC doesn't have anything to do with incremental linking. |
| Depending on what platform you use, it may be possible to tell GCC to |
| use the platform's native linker (e.g., Solaris' ild(1)).</p> |
| |
| |
| </body> |
| </html> |