samples/powerpc-e500v2-linux-gnuspe/reported.by
author |
"Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com> |
|
Thu Jul 28 22:09:31 2011 +0200 (2011-07-28) |
changeset 2573 |
424fa2092ace |
parent 2290 |
ba82eb173bd4
|
permissions |
-rw-r--r-- |
scripts/libc: do not build add-ons by default
Currently, no --enable-add-ons option is passed to libc configure when
"$(do_libc_add_ons_list ,)" is empty, which makes configure automatically search
for present add-ons. In that case, all present add-ons are built, although
no add-on was selected by the user in the config. Moreover, this can make the
configure fail if some non-standard add-ons like eglibc-localedef are present.
This behavior also leads to an inconsistency from a user point of view between
the following cases:
- LIBC_ADDONS_LIST="", LIBC_GLIBC_USE_PORTS=n and THREADS="none" in the config,
which makes "$(do_libc_add_ons_list ,)" return "", so all present add-ons
are built.
- LIBC_ADDONS_LIST="", LIBC_GLIBC_USE_PORTS=n and THREADS!="none" in the
config, which makes "$(do_libc_add_ons_list ,)" return the add-on supporting
the chosen threading implementation, e.g. "nptl", so only this add-on is
built.
This patch disables the building of all add-ons in that case.
It is still possible to build all present add-ons by adding --enable-add-ons to
LIBC_GLIBC_EXTRA_CONFIG_ARRAY.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
yann@2139
|
1 |
reporter_name="Anthony Foiani <anthony.foiani@gmail.com>"
|
yann@2139
|
2 |
reporter_url="http://sourceware.org/ml/crossgcc/2010-09/msg00100.html"
|
yann@2290
|
3 |
reporter_comment="This is a sample config file for Freescale e500v2 processors (e.g., MPC8548,
|
yann@2369
|
4 |
MPC8572). It uses eglibc (for e500/SPE patches) and a recent gcc (4.6.0,
|
yann@2173
|
5 |
for e500v2 DPFP support) and will generate appropriate dual-precision
|
yann@2173
|
6 |
floating point instructions by default.
|
yann@935
|
7 |
|
yann@2173
|
8 |
Note: If building a Linux kernel with this toolchain, you will want to make
|
yann@2173
|
9 |
sure -mno-spe AND -mspe=no are passed to gcc to prevent SPE ABI/instructions
|
yann@2173
|
10 |
from getting into the kernel (which is currently unsupported). At this time,
|
yann@2173
|
11 |
the kernel build system properly passes those two options, but older kernels
|
yann@2173
|
12 |
were only passing -mno-spe by default."
|