diff options
author | Alexey Neyman <stilor@att.net> | 2016-03-30 12:15:54 -0700 |
---|---|---|
committer | Alexey Neyman <stilor@att.net> | 2016-08-23 11:00:27 -0700 |
commit | 82072d0cbc238000fd1547551deb198aa8c8d466 (patch) | |
tree | 47497379bd1d9a1f0c2c2bb264f3e6dc9ab81705 /config/target.in | |
parent | cc86d80da26aa27c382dee5ef44d21f450b3ae60 (diff) | |
download | crosstool-ng-82072d0cbc238000fd1547551deb198aa8c8d466.tar.gz crosstool-ng-82072d0cbc238000fd1547551deb198aa8c8d466.tar.bz2 crosstool-ng-82072d0cbc238000fd1547551deb198aa8c8d466.zip |
multilib: Determine which options may pass through.
On some arches (e.g. MIPS) the options like -mabi do not work if
specified more than once (see the comment in 100-gcc.sh). Therefore,
we need to determine which of the options produced by <arch>.sh can
be passed to multilib builds and which must be removed (i.e., which
options vary among the multilibs).
This presents a chicken-and-egg problem. GCC developers, in their
infinite wisdom, do not allow arbitrary multilib specification to be
supplied to GCC's configure. Instead, the target (and sometimes some
extra options) determine the set of multilibs - which may include
different CPUs, different ABIs, different endianness, different FPUs,
different floating-point ABIs, ... That is, we don't know which parts
vary until we build GCC and ask it.
So, the solution implemented here is:
- For multilib builds, start with empty CT_ARCH_TARGET_CFLAGS/LDFLAGS.
- For multilib builds, require core pass 1. Pass 1 does not build any
target binaries, so at that point, our target options have not been
used yet.
- Provide an API to modify the environment variables for the steps that
follow the current one.
- As a part of multilib-related housekeeping, determine the variable
part of multilibs and filter out these options; pass the rest into
CT_TARGET_CFLAGS/LDFLAGS.
This still does not handle extra dependencies between GCC options (like
-ma implying -mcpu=X -mtune=Y, etc.) but I feel that would complicate
matters too much. Let's leave this until there's a compelling case for
it.
Also, query GCC's sysroot suffix for targets that use it (SuperH,
for example) - the default multilib may not work if the command line
specifies the default option explicitly (%sysroot_suffix_spec is not
aware of multilib defaults).
Signed-off-by: Alexey Neyman <stilor@att.net>
Diffstat (limited to 'config/target.in')
-rw-r--r-- | config/target.in | 4 |
1 files changed, 4 insertions, 0 deletions
diff --git a/config/target.in b/config/target.in index 8cbaabc0..e8f0fe7d 100644 --- a/config/target.in +++ b/config/target.in @@ -65,9 +65,13 @@ config ARCH_REQUIRES_MULTILIB bool select MULTILIB +# Multilib requires 1st core pass (i.e., pass without building libgcc) +# to determine which target cflags vary with multilib and which must be +# passed from the arch configuration. config MULTILIB bool prompt "Build a multilib toolchain (READ HELP!!!)" + select CC_CORE_PASS_1_NEEDED help If you say 'y' here, then the toolchain will also contain the C library optimised for some variants of the selected architecture, besides the |