docs/B - Known issues.txt
author "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Wed Jul 20 23:52:39 2011 +0200 (2011-07-20)
changeset 2565 fbc2b9d638ec
parent 2564 5d4e91c0343e
child 2674 8a612563c04c
permissions -rw-r--r--
docs: update known issues

Document the glibc build failures with male-3.82.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
     1 File.........: B - Known issues.txt
     2 Copyright....: (C) 2010 Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
     3 License......: Creative Commons Attribution Share Alike (CC-by-sa), v2.5
     4 
     5 
     6 Known issues  /
     7 _____________/
     8 
     9 
    10 This files lists the known issues encountered while developing crosstool-NG,
    11 but that could not be addressed before the release.
    12 
    13 The file has one section for each known issue, each section containing four
    14 sub-sections: Symptoms, Explanations, Fix, and Workaround.
    15 
    16 Each section is separated from the others with a lines of at least 4 dashes.
    17 
    18 The following dummy section explains it all.
    19 
    20     --------------------------------
    21     Symptoms:
    22       A one- or two-liner of what you would observe.
    23       Usually, the error message you would see in the build logs.
    24 
    25     Explanations:
    26       An as much as possible in-depth explanations of the context, why it
    27       happens, what has been investigated so far, and possible orientations
    28       as how to try to solve this (eg. URLs, code snippets...).
    29 
    30     Status:
    31       Tells about the status of the issue:
    32         UNCONFIRMED : missing information, or unable, to reproduce, but there
    33                       is consensus that there is an issue somewhere...
    34         CURRENT     : the issue is applicable.
    35         DEPRECATED  : the issue used to apply in some cases, but has not been
    36                       confirmed or reported again lately.
    37         CLOSED      : the issue is no longer valid, and a fix has been added
    38                       either as a patch to this component, and/or as a
    39                       workaround in the scripts and/or the configuration.
    40 
    41     Fix:
    42       What you have to do to fix it, if at all possible.
    43       The fact that there is a fix, and yet this is a known issue means that
    44       time to incorporate the fix in crosstool-NG was missing, or planned for
    45       a future release.
    46 
    47     Workaround:
    48       What you can do to fix it *temporarily*, if at all possible.
    49       A workaround is not a real fix, as it can break other parts of
    50       crosstool-NG, but at least makes you going in your particular case.
    51 
    52 So now, on for the real issues...
    53 
    54 --------------------------------
    55 Symptoms:
    56   gcc is not found, although I *do* have gcc installed.
    57 
    58 Explanations:
    59   This is an issue on at least RHEL systems, where gcc is a symlink to ccache.
    60   Because crosstool-NG create links to gcc for the build and host environment,
    61   those symlinks are in fact pointing to ccache, which then doesn't know how
    62   to run the compiler.
    63 
    64   A possible fix could probably set the environment variable CCACHE_CC to the
    65   actual compiler used.
    66 
    67 Status:
    68   CURRENT
    69 
    70 Fix:
    71   None known.
    72 
    73 Workaround:
    74   Uninstall ccache.
    75 
    76 --------------------------------
    77 Symptoms:
    78   The extract and/or path steps fail under Cygwin.
    79 
    80 Explanations:
    81   This is not related to crosstool-NG. Mounts under Cygwin are by default not
    82   case-sensitive. You have to use so-called "managed" mounts. See:
    83   http://cygwin.com/faq.html section 4, question 32.
    84 
    85 Status:
    86   DEPRECATED
    87 
    88 Fix:
    89   Use "managed" mounts for the directories where you build *and* install your
    90   toolchains.
    91 
    92 Workaround:
    93   None.
    94 
    95 --------------------------------
    96 Symptoms:
    97   uClibc fails to build under Cygwin.
    98 
    99 Explanations:
   100   With uClibc, it is possible to build a cross-ldd. Unfortunately, it is
   101   not (currently) possible to build this cross-ldd under Cygwin.
   102 
   103 Status:
   104   DEPRECATED
   105 
   106 Fix:
   107   None so far.
   108 
   109 Workaround:
   110   Disable the cross-ldd build.
   111 
   112 --------------------------------
   113 Symptoms:
   114   On 64-bit build systems, the glibc (possibly eglibc too) build fails for
   115   64-bit targets, because it can not find libgcc.
   116 
   117 Explanations:
   118   This issue has been observed when the companion libraries are built
   119   statically. For an unknown reason, in this case, the libgcc built by the
   120   core gcc is not located in the same place it is located when building
   121   with shared companion libraries.
   122 
   123 Status:
   124   DEPRECATED
   125 
   126 Fix:
   127   None so far.
   128 
   129 Workaround:
   130   Build shared companion libraries.
   131 
   132 --------------------------------
   133 Symptoms:
   134   libtool.m4: error: problem compiling FC test program
   135 
   136 Explanations:
   137   The gcc build procedure tries to run a Fortran test to see if it has a
   138   working native fortran compiler installed on the build machine, and it
   139   can't find one. A native Fortran compiler is needed (seems to be needed)
   140   to build the Fortran frontend of the cross-compiler.
   141   Even if you don't want to build the Fortran frontend, gcc tries to see
   142   if it has one, but fails. This is no problem, as the Fortran frontend
   143   will not be built. There is nothing to be worry about (unless you do
   144   want to build the Fortran frontend, of course).
   145 
   146 Status:
   147   CURRENT
   148 
   149 Fix:
   150   None so far. It's a spurious error, so there will probably never be
   151   a fix for this issue.
   152 
   153 Workaround:
   154   None needed, it's a spurious error.
   155 
   156 --------------------------------
   157 Symptoms:
   158   unable to detect the exception model
   159 
   160 Explanations:
   161   On some architectures, proper stack unwinding (C++) requires that
   162   setjmp/longjmp (sjlj) be used, while on other architectures do not
   163   need sjlj. On some architectures, gcc is unable to determine whether
   164   sjlj are needed or not.
   165 
   166 Status:
   167   CURRENT
   168 
   169 Fix:
   170   None so far.
   171 
   172 Workaround:
   173   Trying setting use of sjlj to either 'Y' or 'N' (instead of the
   174   default 'M') in the menuconfig, option CT_CC_GCC_SJLJ_EXCEPTIONS
   175   labelled "Use sjlj for exceptions".
   176 
   177 --------------------------------
   178 Symptoms:
   179   configure: error: forced unwind support is required
   180 
   181 Explanations:
   182   The issue seems to be related to building NPTL on old versions
   183   of glibc (and possibly eglibc as well) on some architectures
   184   (seen on powerpc, s390, s390x and x86_64).
   185 
   186 Status:
   187   CURRENT
   188 
   189 Fix:
   190   None so far. It would require some glibc hacking.
   191 
   192 Workaround:
   193   Try setting "Force unwind support" in the "C-library" menu.
   194 
   195 --------------------------------
   196 Symptoms:
   197   glibc start files and headers fail with: [/usr/include/limits.h] Error 1
   198 
   199 Explanations:
   200   The glibc Makefiles break with make-3.82.
   201 
   202 Status:
   203   CURRENT
   204 
   205 Fix:
   206   None so far. It would require some glibc hacking.
   207 
   208 Workaround:
   209   There two possible workarounds:
   210   1- ask crosstool-NG to build make-3.81 just for this build session;
   211   2- manually install make-3.81 to take precedence over the system make.
   212 
   213 --------------------------------