docs/known-issues.txt
author "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Mon Jul 26 00:07:17 2010 +0200 (2010-07-26)
changeset 2039 c5a2e4ee7fb8
parent 1942 dd97222683a3
child 2056 441be7e9dc78
permissions -rw-r--r--
libc-uclibc: move options
yann@771
     1
This files lists the known issues encountered while developping crosstool-NG,
yann@771
     2
but that could not be addressed before the release.
yann@771
     3
yann@771
     4
The file has one section for each known issue, each section containing four
yann@771
     5
sub-sections: Symptoms, Explanations, Fix, and Workaround.
yann@771
     6
yann@771
     7
Each section is separated from the others with a lines of at least 4 dashes.
yann@771
     8
yann@771
     9
The following dummy section explains it all.
yann@771
    10
yann@771
    11
    --------------------------------
yann@771
    12
    Symptoms:
yann@771
    13
      A one-liner of what you would observe.
yann@771
    14
yann@771
    15
    Explanations:
yann@771
    16
      An as much as possible in-depth explanations of the context, why it
yann@771
    17
      happens, what has been investigated so far, and possible orientations
yann@771
    18
      as how to try to solve this (eg. URLs, code snippets...).
yann@771
    19
yann@771
    20
    Fix:
yann@771
    21
      What you have to do to fix it, if at all possible.
yann@771
    22
      The fact that there is a fix, and yet this is a known issue means that
yann@771
    23
      time to incorporate the fix in crosstool-NG was missing, or planned for
yann@771
    24
      a future release.
yann@771
    25
yann@771
    26
    Workaround:
yann@771
    27
      What you can do to fix it *temporarily*, if at all possible.
yann@771
    28
      A workaround is not a real fix, as it can break other parts of
yann@771
    29
      crosstool-NG, but at least makes you going in your particular case.
yann@771
    30
yann@771
    31
So now, on for the real issues...
yann@771
    32
yann@771
    33
--------------------------------
yann@771
    34
Symptoms:
yann@885
    35
  gcc is not found, although I *do* have gcc installed.
yann@885
    36
yann@885
    37
Explanations:
yann@885
    38
  This is an issue on at least RHEL systems, where gcc is a symlink to ccache.
yann@885
    39
  Because crosstool-NG create links to gcc for the build and host environment,
yann@885
    40
  those symlinks are in fact pointing to ccache, which then doesn't know how
yann@885
    41
  to run the compiler.
yann@885
    42
yann@885
    43
  A possible fix could probably set the environment variable CCACHE_CC to the
yann@885
    44
  actual compiler used.
yann@885
    45
yann@885
    46
Fix:
yann@885
    47
  None known.
yann@885
    48
yann@885
    49
Workaround:
yann@885
    50
  Uninstall ccache.
yann@885
    51
yann@885
    52
--------------------------------
yann@1218
    53
Symptoms:
yann@1280
    54
  The extract and/or path steps fail under Cygwin.
yann@1218
    55
yann@1218
    56
Explanations:
yann@1218
    57
  This is not related to crosstool-NG. Mounts under Cygwin are by default not
yann@1218
    58
  case-sensitive. You have to use so-called "managed" mounts. See:
yann@1218
    59
  http://cygwin.com/faq.html section 4, question 32.
yann@1218
    60
yann@1218
    61
Fix:
yann@1218
    62
  Use "managed" mounts for the directories where you build *and* install your
yann@1218
    63
  toolchains.
yann@1218
    64
yann@1218
    65
Workaround:
yann@1218
    66
  None.
yann@1218
    67
yann@1218
    68
--------------------------------
yann@1280
    69
Symptoms:
yann@1280
    70
  uClibc fails to build under Cygwin.
yann@1280
    71
yann@1280
    72
Explanations:
yann@1280
    73
  With uClibc, it is possible to build a cross-ldd. Unfortunately, it is
yann@1280
    74
  not (currently) possible to build this cross-ldd under Cygwin.
yann@1280
    75
yann@1280
    76
Fix:
yann@1280
    77
  None so far.
yann@1280
    78
yann@1280
    79
Workaround:
yann@1280
    80
  Disable the cross-ldd build.
yann@1280
    81
yann@1280
    82
--------------------------------
yann@1942
    83
Symptoms:
yann@1942
    84
  On 64-bit build systems, the glibc (possibly eglibc too) build fails for
yann@1942
    85
  64-bit targets, because it can not find libgcc.
yann@1942
    86
yann@1942
    87
Explanations:
yann@1942
    88
  This issue has been observed when the companion libraries are built
yann@1942
    89
  statically. For an unknown reason, in this case, the libgcc built by the
yann@1942
    90
  core gcc is not located in the same place it is located when building
yann@1942
    91
  with shared companion libraries.
yann@1942
    92
yann@1942
    93
Fix:
yann@1942
    94
  None so far.
yann@1942
    95
yann@1942
    96
Workaround:
yann@1942
    97
  Build shared companion libraries.
yann@1942
    98
yann@1942
    99
--------------------------------
yann@2032
   100
Symptoms:
yann@2032
   101
  While building the final gcc, I get an error message that ends with:
yann@2032
   102
    libtool.m4: error: problem compiling FC test program
yann@2032
   103
yann@2032
   104
Explanations:
yann@2032
   105
  The gc build procedure tries to run a Fortran test to see if it has a
yann@2032
   106
  working native fortran compiler installed on the build machine, and it
yann@2032
   107
  can't find one. A native Fortran compielr is needed (seems to be) to
yann@2032
   108
  build the Fortran frontend of the cross-compiler.
yann@2032
   109
  Even if you don't want to build the Fortran frontend, gcc tries to see
yann@2032
   110
  if it has one, but fails. This is no problem, as the Fortran frontend
yann@2032
   111
  will not be built. There is nothing to be worry about (unless you do
yann@2032
   112
  want to build the Fortran frontend, of course).
yann@2032
   113
yann@2032
   114
Fix:
yann@2032
   115
  None so far. It's a spurious error, so there will probably never be
yann@2032
   116
  a fix for this issue.
yann@2032
   117
yann@2032
   118
Workaround:
yann@2032
   119
  None needed, it's a spurious error.
yann@2032
   120
yann@2032
   121
--------------------------------