docs/known-issues.txt
author "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Wed Jan 06 18:42:41 2010 +0100 (2010-01-06)
changeset 1696 f04fb2d52023
parent 1280 46f27896bfc4
child 1714 5d693a13c84a
permissions -rw-r--r--
complibs/mpfr: add latest version 2.4.2

Note: the MPFR site happens to be down at the time I wrote
this message, and happens to be down quite often.

Once it's back up'n'runnin', I'll mirror as much as possible
the MPFR tarballs on my site, but in the meantime, you'll
have to handle it by yourself (patience...).
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@771
    35
  Seemingly native toolchains do not build.
yann@771
    36
yann@771
    37
Explanations:
yann@771
    38
  Seemingly native toolchains are toolchains that target the same architecture
yann@771
    39
  as the one it is built on, and on which it will run, but the machine tuple
yann@771
    40
  may be different (eg i686 vs. i386, or x86_64-unknown-linux-gnu vs.
yann@771
    41
  x86_64-pc-linux-gnu).
yann@771
    42
yann@771
    43
  This seems to happen when building glibc-2.7 based toolchains only, for
yann@771
    44
  x86 and for x86_64.
yann@771
    45
yann@771
    46
  Only the system part of the tuple (here, linux-gnu) needs to be the same to
yann@885
    47
  trigger the bug. Which means that building a tolchain for either x86 or
yann@885
    48
  x86_64 on either x86 or x86_64 breaks.
yann@771
    49
yann@771
    50
Fix:
yann@771
    51
  None known.
yann@771
    52
yann@771
    53
Workaround:
yann@1551
    54
  It seems that using -O2 in the CFLAGS fixes the problem. It has been
yann@1551
    55
  confirmed in the following threads:
yann@1551
    56
    http://sourceware.org/ml/crossgcc/2009-09/msg00055.html (for glibc)
yann@1551
    57
    http://sourceware.org/ml/crossgcc/2009-10/msg00001.html (for eglibc)
yann@771
    58
yann@771
    59
--------------------------------
yann@885
    60
Symptoms:
yann@885
    61
  gcc is not found, although I *do* have gcc installed.
yann@885
    62
yann@885
    63
Explanations:
yann@885
    64
  This is an issue on at least RHEL systems, where gcc is a symlink to ccache.
yann@885
    65
  Because crosstool-NG create links to gcc for the build and host environment,
yann@885
    66
  those symlinks are in fact pointing to ccache, which then doesn't know how
yann@885
    67
  to run the compiler.
yann@885
    68
yann@885
    69
  A possible fix could probably set the environment variable CCACHE_CC to the
yann@885
    70
  actual compiler used.
yann@885
    71
yann@885
    72
Fix:
yann@885
    73
  None known.
yann@885
    74
yann@885
    75
Workaround:
yann@885
    76
  Uninstall ccache.
yann@885
    77
yann@885
    78
--------------------------------
yann@1218
    79
Symptoms:
yann@1280
    80
  The extract and/or path steps fail under Cygwin.
yann@1218
    81
yann@1218
    82
Explanations:
yann@1218
    83
  This is not related to crosstool-NG. Mounts under Cygwin are by default not
yann@1218
    84
  case-sensitive. You have to use so-called "managed" mounts. See:
yann@1218
    85
  http://cygwin.com/faq.html section 4, question 32.
yann@1218
    86
yann@1218
    87
Fix:
yann@1218
    88
  Use "managed" mounts for the directories where you build *and* install your
yann@1218
    89
  toolchains.
yann@1218
    90
yann@1218
    91
Workaround:
yann@1218
    92
  None.
yann@1218
    93
yann@1218
    94
--------------------------------
yann@1280
    95
Symptoms:
yann@1280
    96
  uClibc fails to build under Cygwin.
yann@1280
    97
yann@1280
    98
Explanations:
yann@1280
    99
  With uClibc, it is possible to build a cross-ldd. Unfortunately, it is
yann@1280
   100
  not (currently) possible to build this cross-ldd under Cygwin.
yann@1280
   101
yann@1280
   102
Fix:
yann@1280
   103
  None so far.
yann@1280
   104
yann@1280
   105
Workaround:
yann@1280
   106
  Disable the cross-ldd build.
yann@1280
   107
yann@1280
   108
--------------------------------