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

Mon Nov 27 00:52:51 UTC 2023

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