Fwd: [PATCH] Update GMP/MPFR/MPC/ISL/gettext to latest release

Joel Sherrill joel.sherrill at gmail.com
Mon Nov 27 01:09:31 UTC 2023


Gdb now needs a couple of those installed. Perhaps they need to be in the
bset.

Also FreeBSD 12 and 13 regularly fail. See build@ for details.

On Sun, Nov 26, 2023, 6:53 PM Chris Johns <chrisj at rtems.org> wrote:

> On 27/11/2023 1:35 am, Sebastian Huber wrote:
> > Hello,
> >
> > could some issues on macOS be cased by explicitly setting the configure
> --build
> > and --host in the RSB:
>
> Thanks for asking on the gcc patches list. I do not know and I also do not
> know
> the rational for the per version numbering on build and host commands we
> are
> being forced to adopt.
>
> I tested the change we have for gcc-12 with gcc-13 and it worked. The main
> effort I resolved is in #4892 [1] and I am not sure where the cross over
> is or
> the status of the problem I found.
>
> Chris
> [1] https://devel.rtems.org/ticket/4892
>
> >
> > -------- Forwarded Message --------
> > Subject: Re: [PATCH] Update GMP/MPFR/MPC/ISL/gettext to latest release
> > Date: Sun, 26 Nov 2023 10:15:27 +0000
> > From: Iain Sandoe <idsandoe at googlemail.com>
> > To: Sebastian Huber <sebastian.huber at embedded-brains.de>
> > CC: Richard Biener <richard.guenther at gmail.com>, GCC Patches
> > <gcc-patches at gcc.gnu.org>
> >
> >
> >
> >> On 26 Nov 2023, at 10:05, Sebastian Huber <
> sebastian.huber at embedded-brains.de>
> >> wrote:
> >>
> >> On 26.11.23 01:35, Iain Sandoe wrote:
> >>>> On 25 Nov 2023, at 21:44, Sebastian Huber
> >>>> <sebastian.huber at embedded-brains.de> wrote:
> >>>>
> >>>> On 25.11.23 14:59, Richard Biener wrote:
> >>>>> On Sat, Nov 25, 2023 at 12:26 PM Sebastian Huber
> >>>>> <sebastian.huber at embedded-brains.de>  wrote:
> >>>>>> contrib/ChangeLog
> >>>>> Did you verify an in-tree build with these works and the testsuite
> >>>>> is clean?
> >>>>
> >>>> I was able to build a native GCC:
> >>>>
> >>>> /tmp/sh/i-native/bin/gcc --version --verbose
> >>>> Using built-in specs.
> >>>> COLLECT_AS_OPTIONS='--version'
> >>>> COLLECT_GCC=/tmp/sh/i-native/bin/gcc
> >>>>
> COLLECT_LTO_WRAPPER=/tmp/sh/i-native/lib/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
> >>>> gcc (GCC) 14.0.0 20231125 (experimental) [master 9c26c91b94e]
> >>>> Copyright (C) 2023 Free Software Foundation, Inc.
> >>>> This is free software; see the source for copying conditions.  There
> is NO
> >>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
> >>>>
> >>>>
> >>>> Target: x86_64-pc-linux-gnu
> >>>> Configured with: /home/EB/sebastian_h/src/gcc/configure
> >>>> --prefix=/tmp/sh/i-native --verbose --enable-checking=yes,rtl
> >>>> --disable-libsanitizer --disable-multilib --disable-bootstrap
> >>>> --enable-languages=c,c++
> >>>> Thread model: posix
> >>>> Supported LTO compression algorithms: zlib
> >>>> gcc version 14.0.0 20231125 (experimental) [master 9c26c91b94e] (GCC)
> >>>> COLLECT_GCC_OPTIONS='--version' '-v' '-mtune=generic' '-march=x86-64'
> >>>> '-dumpdir' 'a-'
> >>>> /tmp/sh/i-native/lib/gcc/x86_64-pc-linux-gnu/14.0.0/cc1 -quiet -v
> help-dummy
> >>>> -quiet -dumpdir a- -dumpbase help-dummy -mtune=generic -march=x86-64
> >>>> -version --version -o /tmp/ccHTKJ5B.s
> >>>> GNU C17 (GCC) version 14.0.0 20231125 (experimental) [master
> 9c26c91b94e]
> >>>> (x86_64-pc-linux-gnu)
> >>>>        compiled by GNU C version 14.0.0 20231122 (experimental)
> [master
> >>>> 6bf66276e3e], GMP version 6.3.0, MPFR version 4.2.1, MPC version
> 1.3.1, isl
> >>>> version isl-0.26-GMP
> >>>> [...]
> >>>>
> >>>> However, I noticed that this was with a disabled bootstrap (for the
> git
> >>>> bisect). The bootstrap fails with an error in ISL 0.26 which seems to
> be a
> >>>> known issue:
> >>>>
> >>>> https://www.mail-archive.com/gcc@gcc.gnu.org/msg101643.html
> >>>>
> >>>> I thought that the GCC prerequisite library maintainers check that a
> new
> >>>> release is able to bootstrap GCC, but this seems to be not the case.
> The
> >>>> older releases have problems to recognize arm64-apple.
> >>> 0.24 (at least) builds fine in-tree on aarch64-apple-darwin21; do you
> have a
> >>> pointer to the recognition issue?
> >>> I’ll try 0.25 in the next few days.
> >>
> >> For the RTEMS Project we had to add patches to ISL, MPC, MPFR for
> ARM64/Darwin
> >> hosts:
> >>
> >>
> https://github.com/RTEMS/rtems-source-builder/commit/5e76e64bccc2d84acb6c37380f2f9d98df3b7382
> >>
> >> Specifically for ISL 0.24 this is:
> >>
> >>
> https://devel.rtems.org/raw-attachment/ticket/4657/fix-mac-arm64-isl-config.patch
> >
> > OK, it is possible (even likely) that the issue you are seeing is
> configuring
> > with “arm64-xxxx-darwinNN”.
> >
> > Although Apple has named the platform Arm64, the configuration used for
> OSS is
> > still “aarch64-apple-darwinNN”
> >
> > When I first began work on the port, I discussed this with the config
> script
> > maintainers, and the end result was that “aarch64-apple-darwinNN” had
> already
> > been adopted (and that was, shall we say, a “firm position” from their
> > perspective), so arm64-apple-darwinNN is not actually canonical.
> >
> > We do use “-arch arm64” in specs etc. that have to interface with system
> tools
> > (like ld etc); but elsewhere the port is ‘aarch64’.
> >
> > e.g.
> > $ ./config.sub arm64-apple-darwin21
> > aarch64-apple-darwin21
> >
> > HTH
> > Iain
> >
> >>
> >> I naively thought that updating to the latest releases would help us to
> get
> >> rid of the patches.
> >>
> >> --
> >> embedded brains GmbH & Co. KG
> >> Herr Sebastian HUBER
> >> Dornierstr. 4
> >> 82178 Puchheim
> >> Germany
> >> email: sebastian.huber at embedded-brains.de
> >> phone: +49-89-18 94 741 - 16
> >> fax:   +49-89-18 94 741 - 08
> >>
> >> Registergericht: Amtsgericht München
> >> Registernummer: HRB 157899
> >> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> >> Unsere Datenschutzerklärung finden Sie hier:
> >> https://embedded-brains.de/datenschutzerklaerung/
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20231126/63fca741/attachment-0001.htm>


More information about the devel mailing list