OpenCores

Line 1...

<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="#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>

  </ol></li>

</ol>

<hr />

<a name="general"></a>

<h1>General information</h1>

<!-- 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 &lt;other configure options&gt;

</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 &amp; 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" &lt;other options&gt;

</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,}" &lt;other options&gt;

</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 &lt;typename T&gt; class foo {

  friend void bar(foo&lt;T&gt;);

</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&lt;int&gt;) { /* ... */ }

void bar(foo&lt;void&gt;) { /* ... */ }

</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 &lt;typename T&gt;

class foo;

template &lt;typename T&gt;

void bar(foo&lt;T&gt;);

template &lt;typename T&gt;

class foo {

  friend void bar&lt;&gt;(foo&lt;T&gt;);

};

template &lt;typename T&gt;

void bar(foo&lt;T&gt;) { /* ... */ }

</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 &amp; 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>" &amp;

"<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>

</body>

</html>

 No newline at end of file

 No newline at end of file

Browse

Tools

Subversion Repositories openrisc_me

[/] [openrisc/] [trunk/] [gnu-src/] [gcc-4.2.2/] [faq.html] - Diff between revs 38 and 154