Commit Graph

12 Commits

Author SHA1 Message Date
Alexey Neyman
8606251585 Add --with-cpu= on 32-bit SPARC
... if building for GLIBC 2.31+.

Signed-off-by: Alexey Neyman <stilor@att.net>
2020-03-03 16:40:33 -08:00
Alexey Neyman
d978290f39 Set --with-cpu-{32,64} for multilib builds
GLIBC 2.31 needs --with-cpu=ultrasparc for both 32/64-bits now, and
--with-cpu only sets the CPU model for the "primary" bitness.

Signed-off-by: Alexey Neyman <stilor@att.net>
2020-02-26 11:05:19 -08:00
Alexey Neyman
57426168ad Convert the rest of packages to new framework
Signed-off-by: Alexey Neyman <stilor@att.net>
2017-07-08 10:57:56 -07:00
Alexey Neyman
55c806a360 Correct warning text to include newer glibc versions
Signed-off-by: Alexey Neyman <stilor@att.net>
2017-03-08 15:47:48 -08:00
Alexey Neyman
bf3eceb5d9 uClibc: Split configuration tweaker into per-arch functions.
Signed-off-by: Alexey Neyman <stilor@att.net>
2016-08-23 11:00:27 -07:00
Alexey Neyman
0fdc1887a7 Change multilib functions to set the variable.
Rather than echo-ing the new value, set the value into the variable with
the name passed as an argument (similar to CT_SanitizeVarDir). This
allows to use CT_DoLog in these functions.

Signed-off-by: Alexey Neyman <stilor@att.net>
2016-08-23 11:00:27 -07:00
Alexey Neyman
3ebc5d0c1e libc/*.sh: Deprecate libc_check_config step.
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>
2016-08-23 11:00:27 -07:00
Alexey Neyman
34ecc718d9 arch/all: Add common function to return multilib target
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>
2016-06-09 17:12:49 -07:00
Alexey Neyman
a60946eb24 arch/sparc: better default CPU when targetting Linux
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>
2016-06-09 17:12:49 -07:00
Yann E. MORIN"
d0cc0b3a56 arch: use the newly introduced target_bits_64
Convert MIPS and Sparc over to using the new target_bits_64 variable.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-05-12 00:09:31 +02:00
Yann E. MORIN"
150f500426 arch: allow adding a suffix to the arch-part of a tuple
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>
2013-01-20 12:58:22 +00:00
Yann E. MORIN"
693cc01f41 arch/sparc: add absic support
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>
2011-04-03 18:22:00 +02:00