docs/known-issues.txt
author "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Thu Jun 11 21:47:19 2009 +0000 (2009-06-11)
branch1.4
changeset 1451 25d050084e98
parent 1280 46f27896bfc4
permissions -rw-r--r--
populate: fix installing dynamic linker 'ld.so'

The dynamic linker, ld.so, needs the execute bit to be set.
Detect tht the library being installed is in fact ld.so and
install it with 0755 instead of 0644.

Fix detecting src == dst.

Use a simpler command to copy src -> dst.

Also change echo to printf, get rid of 'echo -n', which is
highly non-portable.


-------- diffstat follows --------
/trunk/scripts/populate.in | 76 43 33 0 +++++++++++++++++++++++++++++-----------------------
1 file changed, 43 insertions(+), 33 deletions(-)
(transplanted from d7ddcb75e0f703e2ba6d17169167356389224870)
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@1306
    47
  trigger the bug. Which means that building a toolchain for either x86 or
yann@885
    48
  x86_64 on either x86 or x86_64 breaks.
yann@771
    49
yann@1306
    50
  Typically, it is not possible to build the i686-nptl-linux-gnu sample on an
yann@1306
    51
  x86_64 machine, although it might build on an x86 machine.
yann@1306
    52
yann@771
    53
Fix:
yann@771
    54
  None known.
yann@771
    55
yann@771
    56
Workaround:
yann@771
    57
  If this happens for you, stick with glibc-2.6.1 for now.
yann@771
    58
  Or investigate! :-)
yann@771
    59
yann@771
    60
--------------------------------
yann@885
    61
Symptoms:
yann@885
    62
  gcc is not found, although I *do* have gcc installed.
yann@885
    63
yann@885
    64
Explanations:
yann@885
    65
  This is an issue on at least RHEL systems, where gcc is a symlink to ccache.
yann@885
    66
  Because crosstool-NG create links to gcc for the build and host environment,
yann@885
    67
  those symlinks are in fact pointing to ccache, which then doesn't know how
yann@885
    68
  to run the compiler.
yann@885
    69
yann@885
    70
  A possible fix could probably set the environment variable CCACHE_CC to the
yann@885
    71
  actual compiler used.
yann@885
    72
yann@885
    73
Fix:
yann@885
    74
  None known.
yann@885
    75
yann@885
    76
Workaround:
yann@885
    77
  Uninstall ccache.
yann@885
    78
yann@885
    79
--------------------------------
yann@1218
    80
Symptoms:
yann@1280
    81
  The extract and/or path steps fail under Cygwin.
yann@1218
    82
yann@1218
    83
Explanations:
yann@1218
    84
  This is not related to crosstool-NG. Mounts under Cygwin are by default not
yann@1218
    85
  case-sensitive. You have to use so-called "managed" mounts. See:
yann@1218
    86
  http://cygwin.com/faq.html section 4, question 32.
yann@1218
    87
yann@1218
    88
Fix:
yann@1218
    89
  Use "managed" mounts for the directories where you build *and* install your
yann@1218
    90
  toolchains.
yann@1218
    91
yann@1218
    92
Workaround:
yann@1218
    93
  None.
yann@1218
    94
yann@1218
    95
--------------------------------
yann@1280
    96
Symptoms:
yann@1280
    97
  uClibc fails to build under Cygwin.
yann@1280
    98
yann@1280
    99
Explanations:
yann@1280
   100
  With uClibc, it is possible to build a cross-ldd. Unfortunately, it is
yann@1280
   101
  not (currently) possible to build this cross-ldd under Cygwin.
yann@1280
   102
yann@1280
   103
Fix:
yann@1280
   104
  None so far.
yann@1280
   105
yann@1280
   106
Workaround:
yann@1280
   107
  Disable the cross-ldd build.
yann@1280
   108
yann@1280
   109
--------------------------------