OpenCores
URL https://opencores.org/ocsvn/openrisc_me/openrisc_me/trunk

Subversion Repositories openrisc_me

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

Go to most recent revision | Show entire file | Details | Blame | View Log

Rev 38 Rev 154
?rev1line?
?rev2line?
 
 
 
                        GCC Frequently Asked Questions
 
 
 
   The   latest   version   of  this  document  is  always  available  at
 
   [1]http://gcc.gnu.org/faq.html.
 
 
 
   This FAQ tries to answer specific questions concerning GCC. For general
 
   information regarding C, C++, resp. Fortran please check the [2]comp.lang.c
 
   FAQ, [3]comp.std.c++ FAQ, and the [4]Fortran Information page.
 
 
 
   Other GCC-related FAQs: [5]libstdc++-v3, and [6]GCJ.
 
     _________________________________________________________________
 
 
 
                                   Questions
 
 
 
    1. [7]General information
 
         1. [8]How do I get a bug fixed or a feature added?
 
         2. [9]Does GCC work on my platform?
 
    2. [10]Installation
 
         1. [11]How to install multiple versions of GCC
 
         2. [12]Dynamic linker is unable to find GCC libraries
 
         3. [13]libstdc++/libio tests fail badly with --enable-shared
 
         4. [14]GCC can not find GNU as/GNU ld
 
         5. [15]cpp: Usage:... Error
 
         6. [16]Optimizing the compiler itself
 
         7. [17]Why does libiconv get linked into jc1 on Solaris?
 
    3. [18]Testsuite problems
 
         1. [19]How do I pass flags like -fnew-abi to the testsuite?
 
         2. [20]How can I run the test suite with multiple options?
 
    4. [21]Miscellaneous
 
         1. [22]Friend Templates
 
         2. [23]dynamic_cast, throw, typeid don't work with shared libraries
 
         3. [24]Why do I need autoconf, bison, xgettext, automake, etc?
 
         4. [25]Why can't I build a shared library?
 
         5. [26]When building C++, the linker says my constructors, destructors
 
            or virtual tables are undefined, but I defined them
 
     _________________________________________________________________
 
 
 
                              General information
 
 
 
How do I get a bug fixed or a feature added?
 
 
 
   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.
 
     * 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.
 
     * [27]Report the problem to the GCC bug tracking system 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.
 
     * 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.
 
     _________________________________________________________________
 
 
 
Does GCC work on my platform?
 
 
 
   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 [28]latest version is always available at the GCC web site. Reports
 
   of [29]successful builds for several versions of GCC are also available at
 
   the web site.
 
     _________________________________________________________________
 
 
 
                                 Installation
 
 
 
How to install multiple versions of GCC
 
 
 
   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.
 
 
 
   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.
 
 
 
   The  easiest  way  to  do  this  is  to  configure  the  new  GCC with
 
   --prefix=/usr/local/gcc and the older gcc2 with --prefix=/usr/local/gcc2.
 
   Build   and   install   both  compilers.  Then  make  a  symlink  from
 
   /usr/local/bin/gcc to /usr/local/gcc/bin/gcc and from /usr/local/bin/gcc2 to
 
   /usr/local/gcc2/bin/gcc. Create similar links for the "g++", "c++" and "g77"
 
   compiler drivers.
 
 
 
   An   alternative   to   using   symlinks   is   to  configure  with  a
 
   --program-transform-name 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 --prefix 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
 
   --program-transform-name  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:
 
 
 
     --program-transform-name='s,\\\\(.*\\\\),new-\\\\1,'
 
 
 
   With the above --prefix option, that will install the new GCC programs into
 
   /usr/local/gcc/bin   with  names  prefixed  by  "new-".  You  can  use
 
   --program-transform-name if you have multiple versions of GCC, and wish to
 
   be sure about which version you are invoking.
 
 
 
   If you use --prefix, GCC may have difficulty locating a GNU assembler or
 
   linker on your system, [30]GCC can not find GNU as/GNU ld explains how to
 
   deal with this.
 
 
 
   Another  option  that may be easier is to use the --program-prefix= or
 
   --program-suffix= options to configure. So if you're installing GCC 2.95.2
 
   and don't want to disturb the current version of GCC in /usr/local/bin/, you
 
   could do
 
 
 
     configure --program-suffix=-2.95.2 
 
 
 
   This should result in GCC being installed as /usr/local/bin/gcc-2.95.2
 
   instead of /usr/local/bin/gcc.
 
     _________________________________________________________________
 
 
 
Dynamic linker is unable to find GCC libraries
 
 
 
   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
 
   --enable-shared and building GCC.
 
 
 
   GCC does not specify a runpath so that the dynamic linker can find dynamic
 
   libraries at runtime.
 
 
 
   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.
 
 
 
   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.
 
 
 
   SunOS effectively always passed a -R option for every -L option; this was a
 
   bad idea, and so it was removed for Solaris. We should not recreate it.
 
 
 
   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 gcc
 
   -print-prog-name=cc1 to find it). You may add linker flags such as -R or
 
   -rpath, depending on platform and linker, to the *link or *lib specs.
 
 
 
   Another alternative is to install a wrapper script around gcc, g++ or ld
 
   that adds the appropriate directory to the environment variable LD_RUN_PATH
 
   or equivalent (again, it's platform-dependent).
 
 
 
   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 .ml file within libstdc++/config (and also
 
   libg++/config, if you are building libg++), so that $(libdir)/ appears just
 
   before the library name in -soname or -h options.
 
     _________________________________________________________________
 
 
 
GCC can not find GNU as/GNU ld
 
 
 
   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.
 
 
 
   To ensure that GCC finds the GNU assembler (the GNU loader), which are
 
   required by [31]some configurations, 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.
 
 
 
   Another  alternative is to create links to GNU as and ld in any of the
 
   directories  printed  by  the  command  `gcc -print-search-dirs | grep
 
   '^programs:''. The link to `ld' should be named `real-ld' if `ld' 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 gcc directory and in
 
   all the gcc/stage* subdirectories.
 
 
 
   GCC 2.95 allows you to specify the full pathname of the assembler and the
 
   linker  to  use.  The  configure flags are `--with-as=/path/to/as' and
 
   `--with-ld=/path/to/ld'. GCC will try to use these pathnames before looking
 
   for `as' or `(real-)ld' in the standard search dirs. If, at configure-time,
 
   the specified programs are found to be GNU utilities, `--with-gnu-as' and
 
   `--with-gnu-ld' 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 -B/path/ if the
 
   specified filenames exist.
 
     _________________________________________________________________
 
 
 
cpp: Usage:... Error
 
 
 
   If you get an error like this when building GCC (particularly when building
 
   __mulsi3), then you likely have a problem with your environment variables.
 
  cpp: Usage: /usr/lib/gcc-lib/i586-unknown-linux-gnulibc1/2.7.2.3/cpp
 
  [switches] input output
 
 
 
   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.
 
 
 
   Also note '::' in these paths will also cause similar problems.
 
     _________________________________________________________________
 
 
 
Optimizing the compiler itself
 
 
 
   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 -fssa option, you could bootstrap like this:
 
make BOOT_CFLAGS="-O2 -fssa" bootstrap
 
     _________________________________________________________________
 
 
 
Why does libiconv get linked into jc1 on Solaris?
 
 
 
   The Java front end requires iconv. If the compiler used to bootstrap GCC
 
   finds libiconv (because the GNU version of libiconv 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 jc1. This problem does not
 
   show up so often on platforms that have libiconv in a default location (like
 
   /usr/lib) because then both compilers can find a library named libiconv,
 
   even though it is a different library.
 
 
 
   Using --disable-nls at configure-time does not prevent this problem because
 
   jc1 uses iconv even in that case. Solutions include temporarily removing the
 
   GNU libiconv, copying it to a default location such as /usr/lib/, and using
 
   --enable-languages at configure-time to disable Java.
 
     _________________________________________________________________
 
 
 
                              Testsuite problems
 
 
 
How do I pass flags like -fnew-abi to the testsuite?
 
 
 
   If you invoke runtest directly, you can use the --tool_opts option, e.g:
 
  runtest --tool_opts "-fnew-abi -fno-honor-std" 
 
 
 
   Or, if you use make check you can use the make variable RUNTESTFLAGS, e.g:
 
  make RUNTESTFLAGS="--tool_opts '-fnew-abi -fno-honor-std'" check-g++
 
     _________________________________________________________________
 
 
 
How can I run the test suite with multiple options?
 
 
 
   If you invoke runtest directly, you can use the --target_board option, e.g:
 
  runtest --target_board "unix{-fPIC,-fpic,}" 
 
 
 
   Or, if you use make check you can use the make variable RUNTESTFLAGS, e.g:
 
  make RUNTESTFLAGS="--target_board 'unix{-fPIC,-fpic,}'" check-gcc
 
 
 
   Either of these examples will run the tests three times. Once with -fPIC,
 
   once with -fpic, and once with no additional flags.
 
 
 
   This technique is particularly useful on multilibbed targets.
 
     _________________________________________________________________
 
 
 
                                 Miscellaneous
 
 
 
Friend Templates
 
 
 
   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:
 
template  class foo {
 
  friend void bar(foo);
 
}
 
 
 
   The above declaration declares a non-template function named bar, so it must
 
   be explicitly defined for each specialization of foo. A template definition
 
   of bar won't do, because it is unrelated with the non-template declaration
 
   above. So you'd have to end up writing:
 
void bar(foo) { /* ... */ }
 
void bar(foo) { /* ... */ }
 
 
 
   If you meant bar 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:
 
template 
 
class foo;
 
 
 
template 
 
void bar(foo);
 
 
 
template 
 
class foo {
 
  friend void bar<>(foo);
 
};
 
 
 
template 
 
void bar(foo) { /* ... */ }
 
 
 
   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.
 
 
 
   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.
 
     _________________________________________________________________
 
 
 
dynamic_cast, throw, typeid don't work with shared libraries
 
 
 
   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 std::type_info 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.
 
     * For a program which is linked against a shared library, no additional
 
       precautions are needed.
 
     * You cannot create a shared library with the "-Bsymbolic" option, as that
 
       prevents the resolution described above.
 
     * If you use dlopen 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 "-E" flag (you will have to specify this as
 
       "-Wl,-E" if you are invoking the linker in the usual manner from the
 
       compiler driver, g++). You must also make the external symbols in the
 
       loaded library available for subsequent libraries by providing the
 
       RTLD_GLOBAL flag to dlopen. The symbol resolution can be immediate or
 
       lazy.
 
 
 
   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 not an exhaustive list of the kind of objects which have vague linkage
 
   and are expected to be resolved during linking & loading.)
 
 
 
   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].
 
 
 
   For more details about the way that GCC implements these and other C++
 
   features, please read the [32]ABI specification. Note the std::type_info
 
   objects  which  must  be resolved all begin with "_ZTS". Refer to ld's
 
   documentation for a description of the "-E" & "-Bsymbolic" flags.
 
     _________________________________________________________________
 
 
 
Why do I need autoconf, bison, xgettext, automake, etc?
 
 
 
   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.
 
 
 
   These include, but are not necessarily limited to autoconf, automake, bison,
 
   and xgettext.
 
 
 
   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.
 
 
 
   An easy way to work around this problem is to use the gcc_update script in
 
   the contrib subdirectory of GCC, which handles this transparently without
 
   requiring installation of any additional tools.
 
 
 
   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.
 
 
 
   In    general,    the   current   versions   of   these   tools   from
 
   [33]ftp://ftp.gnu.org/gnu/ 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 [34]ftp://gcc.gnu.org/pub/gcc/infrastructure/
 
   for any special versions of packages.
 
     _________________________________________________________________
 
 
 
Why can't I build a shared library?
 
 
 
   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'.
 
 
 
   This kind of error occurs when you've failed to provide proper flags to gcc
 
   when linking the shared library.
 
 
 
   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.
 
 
 
   Adding the proper PIC option (-fpic or -fPIC) to the link line which creates
 
   the shared library will fix this problem on targets that support PIC in this
 
   manner. For example:
 
        gcc -c -fPIC myfile.c
 
        gcc -shared -o libmyfile.so -fPIC myfile.o
 
     _________________________________________________________________
 
 
 
When building C++, the linker says my constructors, destructors or virtual
 
tables are undefined, but I defined them
 
 
 
   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.
 
 
 
   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.
 
 
 
   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.
 
 
 
References
 
 
 
   1. http://gcc.gnu.org/faq.html
 
   2. http://c-faq.com/
 
   3. http://www.comeaucomputing.com/csc/faq.html
 
   4. http://www.fortran.com/fortran/info.html
 
   5. http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html
 
   6. http://gcc.gnu.org/java/faq.html
 
   7. http://gcc.gnu.org/faq.html#general
 
   8. http://gcc.gnu.org/faq.html#support
 
   9. http://gcc.gnu.org/faq.html#platforms
 
  10. http://gcc.gnu.org/faq.html#installation
 
  11. http://gcc.gnu.org/faq.html#multiple
 
  12. http://gcc.gnu.org/faq.html#rpath
 
  13. http://gcc.gnu.org/faq.html#rpath
 
  14. http://gcc.gnu.org/faq.html#gas
 
  15. http://gcc.gnu.org/faq.html#environ
 
  16. http://gcc.gnu.org/faq.html#optimizing
 
  17. http://gcc.gnu.org/faq.html#iconv
 
  18. http://gcc.gnu.org/faq.html#testsuite
 
  19. http://gcc.gnu.org/faq.html#testoptions
 
  20. http://gcc.gnu.org/faq.html#multipletests
 
  21. http://gcc.gnu.org/faq.html#misc
 
  22. http://gcc.gnu.org/faq.html#friend
 
  23. http://gcc.gnu.org/faq.html#dso
 
  24. http://gcc.gnu.org/faq.html#generated_files
 
  25. http://gcc.gnu.org/faq.html#picflag-needed
 
  26. http://gcc.gnu.org/faq.html#vtables
 
  27. http://gcc.gnu.org/bugs.html
 
  28. http://gcc.gnu.org/install/specific.html
 
  29. http://gcc.gnu.org/buildstat.html
 
  30. http://gcc.gnu.org/faq.html#gas
 
  31. http://gcc.gnu.org/install/specific.html
 
  32. http://www.codesourcery.com/cxx-abi/
 
  33. ftp://ftp.gnu.org/gnu/
 
  34. ftp://gcc.gnu.org/pub/gcc/infrastructure/

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.