- Glibc configure args and tuple need adjustment on SuperH
- Only allow "both endian" and "with CPU" for unspecified arch
variant. May reconsider endianness (was breaking things before
adjusting glibc tuple)
- Retire non-multilib sample, it should be a subset of the
multilib one now.
Signed-off-by: Alexey Neyman <stilor@att.net>
1. On SuperH, configuring GCC with explicit variant of the CPU
(like "sh4") limits the default set of multilibs to just that CPU
and requires --with-multilib-list to change. Allow for "unspecified"
variant, so that we can defer to GCC to determine the list.
2. Support toolchains with both endiannesses at the same time.
3. Add a SuperH/newlib sample
4. Add more flags processing for uClibc
Signed-off-by: Alexey Neyman <stilor@att.net>
(see the comments in the code for details on the issue)
Old workaround in 100-gcc.sh stopped working (probably, due to one
of GCC version upgrades), so switch to the other approach originally
described there: adjust the list of multilibs to not include the
default target explicitly.
Signed-off-by: Alexey Neyman <stilor@att.net>
This step was only used in uClibc. However, with upcoming multilib, the
config management will have to be done for each variant differently,
anyway.
uClibc was the only user of libc_check_config step, as well as
CT_CONFIG_DIR directory. Retire these.
Two other clean-ups in uClibc.sh:
- KERNEL_HEADERS check seems to be bogus, this config option is not
present even in 0.9.30 - which is not supported already.
- SHARED_LIB_LOADER_PREFIX was renamed to MULTILIB_DIR in 0.9.31,
according to ChangeLog - and MULTILIB_DIR is passed from command line
instead.
Signed-off-by: Alexey Neyman <stilor@att.net>
This code was abstracted out of Cody P Schafer's multilib patch.
It doesn't seem right having architecture dependent code in a
specific libc implementation script. So this patch breaks it out into
scripts/build/arch/<arch>.sh in a function:
multilib_target_to_build="$(CT_DoArchMultilibTarget 'multi_flags'
'target-in')"
Note that this function gets called on each multilib variant with
different sets of compiler flags supplied in 'multi_flags'. The caller
will first filter the flags so that there is no conflicting flags (e.g.,
no '-m32 -m64') supplied.
Changed by Alexey Neyman:
- make option analysis check specific option rather than match global
options string as a whole. Moreover, old code did not handle multiple
options in the same multilib, e.g. '-m64 -mlittle'.
- fixed substitutions in powerpc.sh (*le variants did not match the
pattern in the shell parameter expansion)
- make s390.sh actually apply the flags it gathered from the options.
- straighten the spaghetti in x86.sh by setting two flags, arch & abi.
Also, do not depend on "gnu" being the last part - we can have
'*-uclibcx32', for example.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: Ray Donnelly <ray.donnelly@gmail.com>
Signed-off-by: Alexey Neyman <stilor@att.net>
For some architectures, it is legit to have an alternate value in the
'architecture' part of the tuple. For example:
armv5te-*
armv7a8-*
Besides, some packages expect the tuple to reflect the arch variant
(eg. openMPI) to detect the variant's capabilities (eg. atomic
primitives).
This patch adds an option for the user to specify a suffix to be added
to the arch-part of the tuple.
Signed-off-by: Willy Tarreau <w@1wt.eu>
Message-ID: <20130120225822.GS6838@1wt.eu>
Patch-Id: 213994
[yann.morin.1998@free.fr: make it a suffix, not an override]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
