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