mirror of
https://github.com/crosstool-ng/crosstool-ng.git
synced 2024-12-21 05:43:09 +00:00
100 lines
3.0 KiB
Plaintext
100 lines
3.0 KiB
Plaintext
This files lists the known issues encountered while developping crosstool-NG,
|
|
but that could not be addressed before the release.
|
|
|
|
The file has one section for each known issue, each section containing four
|
|
sub-sections: Symptoms, Explanations, Fix, and Workaround.
|
|
|
|
Each section is separated from the others with a lines of at least 4 dashes.
|
|
|
|
The following dummy section explains it all.
|
|
|
|
--------------------------------
|
|
Symptoms:
|
|
A one-liner of what you would observe.
|
|
|
|
Explanations:
|
|
An as much as possible in-depth explanations of the context, why it
|
|
happens, what has been investigated so far, and possible orientations
|
|
as how to try to solve this (eg. URLs, code snippets...).
|
|
|
|
Fix:
|
|
What you have to do to fix it, if at all possible.
|
|
The fact that there is a fix, and yet this is a known issue means that
|
|
time to incorporate the fix in crosstool-NG was missing, or planned for
|
|
a future release.
|
|
|
|
Workaround:
|
|
What you can do to fix it *temporarily*, if at all possible.
|
|
A workaround is not a real fix, as it can break other parts of
|
|
crosstool-NG, but at least makes you going in your particular case.
|
|
|
|
So now, on for the real issues...
|
|
|
|
--------------------------------
|
|
Symptoms:
|
|
gcc is not found, although I *do* have gcc installed.
|
|
|
|
Explanations:
|
|
This is an issue on at least RHEL systems, where gcc is a symlink to ccache.
|
|
Because crosstool-NG create links to gcc for the build and host environment,
|
|
those symlinks are in fact pointing to ccache, which then doesn't know how
|
|
to run the compiler.
|
|
|
|
A possible fix could probably set the environment variable CCACHE_CC to the
|
|
actual compiler used.
|
|
|
|
Fix:
|
|
None known.
|
|
|
|
Workaround:
|
|
Uninstall ccache.
|
|
|
|
--------------------------------
|
|
Symptoms:
|
|
The extract and/or path steps fail under Cygwin.
|
|
|
|
Explanations:
|
|
This is not related to crosstool-NG. Mounts under Cygwin are by default not
|
|
case-sensitive. You have to use so-called "managed" mounts. See:
|
|
http://cygwin.com/faq.html section 4, question 32.
|
|
|
|
Fix:
|
|
Use "managed" mounts for the directories where you build *and* install your
|
|
toolchains.
|
|
|
|
Workaround:
|
|
None.
|
|
|
|
--------------------------------
|
|
Symptoms:
|
|
uClibc fails to build under Cygwin.
|
|
|
|
Explanations:
|
|
With uClibc, it is possible to build a cross-ldd. Unfortunately, it is
|
|
not (currently) possible to build this cross-ldd under Cygwin.
|
|
|
|
Fix:
|
|
None so far.
|
|
|
|
Workaround:
|
|
Disable the cross-ldd build.
|
|
|
|
--------------------------------
|
|
Symptoms:
|
|
On 64-bit build systems, the glibc (possibly eglibc too) build fails for
|
|
64-bit targets, because it can not find libgcc.
|
|
|
|
Explanations:
|
|
This issue has been observed when the companion libraries are built
|
|
statically. For an unknown reason, in this case, the libgcc built by the
|
|
core gcc is not located in the same place it is located when building
|
|
with shared companion libraries.
|
|
|
|
Fix:
|
|
None so far.
|
|
|
|
Workaround:
|
|
Build shared companion libraries.
|
|
|
|
--------------------------------
|