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 <idsan...@googlemail.com> > To: Sebastian Huber <sebastian.hu...@embedded-brains.de> > CC: Richard Biener <richard.guent...@gmail.com>, GCC Patches > <gcc-patc...@gcc.gnu.org> > > > >> On 26 Nov 2023, at 10:05, Sebastian Huber >> <sebastian.hu...@embedded-brains.de> >> wrote: >> >> On 26.11.23 01:35, Iain Sandoe wrote: >>>> On 25 Nov 2023, at 21:44, Sebastian Huber >>>> <sebastian.hu...@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.hu...@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.hu...@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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
