Age | Commit message (Collapse) | Author | Files | Lines |
|
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>
|
|
By default, sparc64-*-linux is configured with -mcpu=v9. However,
according to https://sourceware.org/ml/libc-alpha/2005-12/msg00027.html:
"There is no Linux sparc64 port that runs on non-UltraSPARC-I+ ISA
CPUs."
v9 is such a "non-UltraSPARC-I+ ISA CPU", so it makes no sense to
default to v9 when targetting Linux.
Change the default to ultrasparc, even though it can suboptimally
schedule instructions for newer SPARC CPUs. See the pending patch:
https://patchwork.ozlabs.org/patch/409424/
Signed-off-by: Alexey Neyman <stilor@att.net>
|
|
Convert MIPS and Sparc over to using the new target_bits_64 variable.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
|
|
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>
|
|
Add support for building SPARC targeted toolchain.
With this patch I have built a working sparc V8 (32 toolchain).
Testing shows that not all gcc versions works well:
4.4.1 OK (kernel builds and the final kernel can boot)
4.4.2 Not tested
4.4.3 Not tested
4.4.4 BAD (Kernel can build but fails during boot)
4.4.5 BAD (Kernel can build but fails during boot)
4.5.1 BAD (Build fails with a spill related ICE - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35664)
4.5.2 OK (kernel builds and boots)
I have successfully been using the 4.5.2 version for a few months.
This patch does not add support for the LEON variant.
That may come later.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
[yann.morin.1998@anciens.enib.fr: for 32-bit, default CT_TARGET_ARCH is OK]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
|