Re: [RSB PATCH] 6: Merge the MacOS M silicon patch from gcc-12 to gcc-13
Hello, On 18.12.2023 07:05, Chris Johns wrote: On 16/12/2023 2:04 am, Cedric Berger wrote: Hello Heinz, On 15.12.2023 10:44, Heinz Junkes wrote: HI, I can follow Cedric's reasoning. Even if I was the initiator of this discussion. I use RTEMS in my lectures/exercises, among other things, and have always been able to give the students freedom which laptops with which OS they wanted to use. And there are many of them with used older laptops. Intel Macs, for example. But you can also use a VM with Linux on all these systems. It might then be okay to communicate openly that there will be no more support for Macs in the future. Just to be clear: I'm not advocating dropping Mac support, just dropping the support for the old intel-based ones (the ones with issues right now). Mac with M1/M2/M3 work fine with the latest tooling. I think there is a middle ground here and that means some investigation is needed to determine what works and what is at issue then deciding how much further work is done. I have done some of this. The results are based on what I have working: Builds: Sonoma Well, if it works on Sonoma (the latest MacOS version), then IMO that's all that matter. So if the middle ground is to only support the latest MacOS version (when RTEMS 6.0 is released) I think this is totally reasonnable. It is true that the first iterations of a new MacOS release (14.0, 14.1) is often buggy, and then gets stabilised around the .2 version, but we're past that now. Cedric Montery Big Sur Fails: Ventura The failure on Ventura is in GMP called from MPFR. Running the GMP tests a number fail and removing --disable-shared improves the test results but GCC does not build. I have not looked any further. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [RSB PATCH] 6: Merge the MacOS M silicon patch from gcc-12 to gcc-13
On 18/12/2023 8:50 pm, Karel Gardas wrote: > On 12/18/23 07:05, Chris Johns wrote: >>> Mac with M1/M2/M3 work fine with the latest tooling. >> >> I think there is a middle ground here and that means some investigation is >> needed to determine what works and what is at issue then deciding how much >> further work is done. I have done some of this. The results are based on >> what I >> have working: >> >> Builds: >> >> Sonoma >> Montery >> Big Sur >> >> Fails: >> >> Ventura >> >> The failure on Ventura is in GMP called from MPFR. Running the GMP tests a >> number fail and removing --disable-shared improves the test results but GCC >> does >> not build. I have not looked any further. > > Just a rant. > > IIRC when Ventura cames it was a disaster for RSB since on Monterey this > worked > and on Ventura it stopped. I think that was the removal of Python from MacOS. > IIRC less RAM on system shows more sensibility to > Ventura problems. And IIRC you were the person who solved this somehow. Yes > Does this mean we're back to the original state with Ventura making troubles > again? It is the different problem. I suspect something in Xcode and GMP have issues that are not present on the other builds of MacOS and Xcode. > I'm not sure if this is even technically possible (partly due to how > Apple supports OS reverts) to test every version of Ventura released by Apple > to > see reliably if whole family is sick or there are some versions which may be > recommended for use. E.g. Ventura spans from 13.0 to 13.5 already... The issue is a pretty simple call by the compiler to MPFR then GMP to convert an ASCII real number to binary. The call crashes the compiler. I suspect something is not right as the `make test` for GMP fails. I tested older versions that use to work and they also fail. A solution is create a suitable bug report and to post to GMP for them to look into. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [RSB PATCH] 6: Merge the MacOS M silicon patch from gcc-12 to gcc-13
On 12/18/23 07:05, Chris Johns wrote: Mac with M1/M2/M3 work fine with the latest tooling. I think there is a middle ground here and that means some investigation is needed to determine what works and what is at issue then deciding how much further work is done. I have done some of this. The results are based on what I have working: Builds: Sonoma Montery Big Sur Fails: Ventura The failure on Ventura is in GMP called from MPFR. Running the GMP tests a number fail and removing --disable-shared improves the test results but GCC does not build. I have not looked any further. Just a rant. IIRC when Ventura cames it was a disaster for RSB since on Monterey this worked and on Ventura it stopped. IIRC less RAM on system shows more sensibility to Ventura problems. And IIRC you were the person who solved this somehow. Does this mean we're back to the original state with Ventura making troubles again? I'm not sure if this is even technically possible (partly due to how Apple supports OS reverts) to test every version of Ventura released by Apple to see reliably if whole family is sick or there are some versions which may be recommended for use. E.g. Ventura spans from 13.0 to 13.5 already... Perhaps doable on VM... Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [RSB PATCH] 6: Merge the MacOS M silicon patch from gcc-12 to gcc-13
On 16/12/2023 2:04 am, Cedric Berger wrote: > Hello Heinz, > > On 15.12.2023 10:44, Heinz Junkes wrote: >> HI, >> I can follow Cedric's reasoning. Even if I was the initiator of this >> discussion. >> >> I use RTEMS in my lectures/exercises, among other things, and have always >> been >> able to give the students >> freedom which laptops with which OS they wanted to use. And there are many of >> them with used >> older laptops. Intel Macs, for example. >> >> But you can also use a VM with Linux on all these systems. >> >> It might then be okay to communicate openly that there will be no more >> support >> for Macs in the future. > > Just to be clear: I'm not advocating dropping Mac support, just dropping the > support for the old intel-based ones (the ones with issues right now). > > Mac with M1/M2/M3 work fine with the latest tooling. I think there is a middle ground here and that means some investigation is needed to determine what works and what is at issue then deciding how much further work is done. I have done some of this. The results are based on what I have working: Builds: Sonoma Montery Big Sur Fails: Ventura The failure on Ventura is in GMP called from MPFR. Running the GMP tests a number fail and removing --disable-shared improves the test results but GCC does not build. I have not looked any further. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [RSB PATCH] 6: Merge the MacOS M silicon patch from gcc-12 to gcc-13
Hello Heinz, On 15.12.2023 10:44, Heinz Junkes wrote: HI, I can follow Cedric's reasoning. Even if I was the initiator of this discussion. I use RTEMS in my lectures/exercises, among other things, and have always been able to give the students freedom which laptops with which OS they wanted to use. And there are many of them with used older laptops. Intel Macs, for example. But you can also use a VM with Linux on all these systems. It might then be okay to communicate openly that there will be no more support for Macs in the future. Just to be clear: I'm not advocating dropping Mac support, just dropping the support for the old intel-based ones (the ones with issues right now). Mac with M1/M2/M3 work fine with the latest tooling. Cedric ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [RSB PATCH] 6: Merge the MacOS M silicon patch from gcc-12 to gcc-13
HI, I can follow Cedric's reasoning. Even if I was the initiator of this discussion. I use RTEMS in my lectures/exercises, among other things, and have always been able to give the students freedom which laptops with which OS they wanted to use. And there are many of them with used older laptops. Intel Macs, for example. But you can also use a VM with Linux on all these systems. It might then be okay to communicate openly that there will be no more support for Macs in the future. Best regards Heinz > On 8. Dec 2023, at 14:19, Cedric Berger wrote: > > Oh, so this is an mac intel issue then. > I'm gonna make the suggestion do just remove support for Intel Macs for RTEMS > 6.0. > I mean, what is the number of developpers who: > 1) Will release a product based on RTEMS 6 (out in 2024 hopefully) > 2) Have enough money to buy an Intel MacBook > 3) Do not have enough money to upgrade 4 years later, especially with the 3x > compile speed improvements the M1/2/3 brings? > My guess is zero. And there is always the possiblity to use a free Ubuntu MV > on these obsolete macs. > I know the senior RTEMS developpers are very very busy, so I (selfishly) > would prefer if they use their time for something more productive :) > Here at Precidata for example, we've put our product developpement with RTEMS > on hold for the past 5 months, because of bug #4923 (STM32h7 FPU corrupted on > return from IRQ). > So may I humbly suggest to forget obsolete developpement platforms and focus > energy on new targets? > Thanks for your answers and all your work. > Cedric > smime.p7s Description: S/MIME cryptographic signature ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [RSB PATCH] 6: Merge the MacOS M silicon patch from gcc-12 to gcc-13
Hello, On 04.12.2023 22:37, Chris Johns wrote: The issue has been resolved in gmp-6.3.0 for M silicon. I am how looking at: https://lists.rtems.org/pipermail/users/2023-October/068894.html and the crash is in a GMP call via MPFR. This is on Intel silicon on Ventura. I have just run `make check` on the RSB build of GMP and it is not great: Testsuite summary for GNU MP 6.3.0 # TOTAL: 53 # PASS: 10 # SKIP: 1 # XFAIL: 0 # FAIL: 42 # XPASS: 0 # ERROR: 0 Oh, so this is an mac intel issue then. I'm gonna make the suggestion do just remove support for Intel Macs for RTEMS 6.0. I mean, what is the number of developpers who: 1) Will release a product based on RTEMS 6 (out in 2024 hopefully) 2) Have enough money to buy an Intel MacBook 3) Do not have enough money to upgrade 4 years later, especially with the 3x compile speed improvements the M1/2/3 brings? My guess is zero. And there is always the possiblity to use a free Ubuntu MV on these obsolete macs. I know the senior RTEMS developpers are very very busy, so I (selfishly) would prefer if they use their time for something more productive :) Here at Precidata for example, we've put our product developpement with RTEMS on hold for the past 5 months, because of bug #4923 (STM32h7 FPU corrupted on return from IRQ). So may I humbly suggest to forget obsolete developpement platforms and focus energy on new targets? Thanks for your answers and all your work. Cedric ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [RSB PATCH] 6: Merge the MacOS M silicon patch from gcc-12 to gcc-13
Following up building gmp-6.3.0 on Intel MacOS Ventura. These are stand alone builds done by hand: The RSB check results: On 5/12/2023 8:37 am, Chris Johns wrote: > > Testsuite summary for GNU MP 6.3.0 > > # TOTAL: 53 > # PASS: 10 > # SKIP: 1 > # XFAIL: 0 > # FAIL: 42 > # XPASS: 0 > # ERROR: 0 Default: ./configure && make && make check produces: Testsuite summary for GNU MP 6.3.0 # TOTAL: 53 # PASS: 45 # SKIP: 1 # XFAIL: 0 # FAIL: 7 # XPASS: 0 # ERROR: 0 Disable shared libraries: ./configure --disable-shared && make && make check produces: Testsuite summary for GNU MP 6.3.0 # TOTAL: 53 # PASS: 10 # SKIP: 1 # XFAIL: 0 # FAIL: 42 # XPASS: 0 # ERROR: 0 It seems the `--disable-shared` option on Intel MacOS causes problems. I add `--disable-shared` to the building of these packages to avoid any shared library issues in the our built tools. I have no idea if this is an issue as gcc, gdb etc may statically link. It would be nice to confirm this so if someone is interesting in taking look it would be appreciated? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [RSB PATCH] 6: Merge the MacOS M silicon patch from gcc-12 to gcc-13
On 4/12/2023 7:13 pm, Cedric Berger wrote: > Hello, > > On 28.11.2023 03:00, Chris Johns wrote: >> On 27/11/2023 6:43 pm, Cedric Berger wrote: >>> Hello, >>> >>> On 24.11.2023 08:36, Sebastian Huber wrote: Would updating to ISL 0.26 and MPC 1.3.1 fix this issue also? >>> I just tried in on my fully up-to-date M1 Pro (macOS Sonoma 14.1.1, Xcode >>> 15.0.1) >>> >>> Short answer: everything works well without issues (configure, make, check) >>> >>> I just installed the following packages successively: >>> >>> - https://gmplib.org/download/gmp/gmp-6.3.0.tar.xz >>> - https://www.mpfr.org/mpfr-current/mpfr-4.2.1.tar.gz >>> - https://ftp.gnu.org/gnu/mpc/mpc-1.3.1.tar.gz >>> - https://libisl.sourceforge.io/isl-0.26.tar.gz >>> >>> by simply extracting the archive and doing: >>> >>> ./configure >>> make >>> make check >>> sudo make install >> Is this a native build? > Yes >> This seems to resolve the OS support part which is good >> however is the other issue of bad code execution in GMP fixed? > > Could you point me to the problem? The issue has been resolved in gmp-6.3.0 for M silicon. I am how looking at: https://lists.rtems.org/pipermail/users/2023-October/068894.html and the crash is in a GMP call via MPFR. This is on Intel silicon on Ventura. I have just run `make check` on the RSB build of GMP and it is not great: Testsuite summary for GNU MP 6.3.0 # TOTAL: 53 # PASS: 10 # SKIP: 1 # XFAIL: 0 # FAIL: 42 # XPASS: 0 # ERROR: 0 > In any case I ran make check, so at least for all the builtin tests, there is > no > issues. Are you checking the RSB built package or a stand along configure and compile build? >> This only showed >> up when the cross-compiled libraries are built? > > These libraries are only used by gcc itself right? Yes. An example of the usage can be seen in the above crash building the libgcc div3c module. The back trace is: thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xd5) * frame #0: 0x.. frame #1: 0x.. cc1`__gmpn_bc_set_str + 1370 frame #2: 0x.. cc1`parsed_string_to_mpfr() at strtofr.c:555:20 [opt] frame #3: 0x.. cc1`mpfr_strtofr() at strtofr.c:965:13 [opt] frame #4: 0x.. cc1`real_from_string(r=0x7ff7bfefb350, str="1.79769313486231570814527423731704357e+308") at real.cc:2152:17 [opt] > Why would you cross-compile these libraries? Sorry if I was not clear. Those libraries are not being cross-compiled, it things like libgcc that are and in this case of the crash posted here the failure appears when building that code. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [RSB PATCH] 6: Merge the MacOS M silicon patch from gcc-12 to gcc-13
Hello, On 28.11.2023 05:12, Chris Johns wrote: -https://libisl.sourceforge.io/isl-0.26.tar.gz This does not build on my M2 with Sonoma and the latest Xcode. Something about a missing constructor. This is so weird, it should make no difference with my system. Full build log below. Cedric Cedrics-MBP:X cedric$ ls -lsa total 6784 0 drwxr-xr-x 3 cedric staff 96 Dec 4 09:15 . 0 drwxr-x---+ 157 cedric staff 5024 Dec 2 16:50 .. 6784 -rw-r--r-- 1 cedric staff 2902641 Apr 2 2023 isl-0.26.tar.gz Cedrics-MBP:X cedric$ uname -a Darwin Cedrics-MBP 23.1.0 Darwin Kernel Version 23.1.0: Mon Oct 9 21:27:24 PDT 2023; root:xnu-10002.41.9~6/RELEASE_ARM64_T6000 arm64 Cedrics-MBP:X cedric$ gcc --version Apple clang version 15.0.0 (clang-1500.0.40.1) Target: arm64-apple-darwin23.1.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin Cedrics-MBP:X cedric$ tar zxf isl-0.26.tar.gz Cedrics-MBP:X cedric$ cd isl-0.26 Cedrics-MBP:isl-0.26 cedric$ ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a race-free mkdir -p... ././install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether make supports nested variables... (cached) yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether the compiler supports GNU C... yes checking whether gcc accepts -g... yes checking for gcc option to enable C11 features... none needed checking whether gcc understands -c and -o together... yes checking whether make supports the include directive... yes (GNU style) checking dependency style of gcc... gcc3 checking for g++... g++ checking whether the compiler supports GNU C++... yes checking whether g++ accepts -g... yes checking for g++ option to enable C++11 features... none needed checking dependency style of g++... gcc3 checking how to run the C preprocessor... gcc -E checking build system type... aarch64-apple-darwin23.1.0 checking for aarch64-apple-darwin23.1.0-gcc... no checking for gcc... gcc checking whether the compiler supports GNU C... yes checking whether gcc accepts -g... yes checking for gcc option to enable C11 features... none needed checking whether gcc understands -c and -o together... yes checking dependency style of gcc... gcc3 checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking how to run the C preprocessor... gcc -E checking for C compiler vendor... clang checking host system type... aarch64-apple-darwin23.1.0 checking for a sed that does not truncate output... /usr/bin/sed checking whether C compiler accepts -g -O2... yes checking whether the compiler supports function __attribute__((__warn_unused_result__))... yes checking for __attribute__... yes checking for grep that handles long lines and -e... /usr/bin/grep checking whether g++ supports C++11 features with -std=c++11... yes checking whether g++ -std=c++11 supports C++17 features by default... no checking whether g++ -std=c++11 supports C++17 features with -std=gnu++17... yes checking for grep that handles long lines and -e... (cached) /usr/bin/grep checking how to print strings... printf checking for a sed that does not truncate output... (cached) /usr/bin/sed checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for ld used by gcc... /Library/Developer/CommandLineTools/usr/bin/ld checking if the linker (/Library/Developer/CommandLineTools/usr/bin/ld) is GNU ld... no checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... rm: conftest.dSYM: is a directory BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 786432 checking how to convert aarch64-apple-darwin23.1.0 file names to aarch64-apple-darwin23.1.0 format... func_convert_file_noop checking how to convert aarch64-apple-darwin23.1.0 file names to toolchain format... func_convert_file_noop checking for /Library/Developer/CommandLineTools/usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for ar... ar checking for archiver @FILE support... rm: conftest.dSYM: is a directory no checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm
Re: [RSB PATCH] 6: Merge the MacOS M silicon patch from gcc-12 to gcc-13
Hello, On 28.11.2023 03:00, Chris Johns wrote: On 27/11/2023 6:43 pm, Cedric Berger wrote: Hello, On 24.11.2023 08:36, Sebastian Huber wrote: Would updating to ISL 0.26 and MPC 1.3.1 fix this issue also? I just tried in on my fully up-to-date M1 Pro (macOS Sonoma 14.1.1, Xcode 15.0.1) Short answer: everything works well without issues (configure, make, check) I just installed the following packages successively: - https://gmplib.org/download/gmp/gmp-6.3.0.tar.xz - https://www.mpfr.org/mpfr-current/mpfr-4.2.1.tar.gz - https://ftp.gnu.org/gnu/mpc/mpc-1.3.1.tar.gz - https://libisl.sourceforge.io/isl-0.26.tar.gz by simply extracting the archive and doing: ./configure make make check sudo make install Is this a native build? Yes This seems to resolve the OS support part which is good however is the other issue of bad code execution in GMP fixed? Could you point me to the problem? In any case I ran make check, so at least for all the builtin tests, there is no issues. This only showed up when the cross-compiled libraries are built? These libraries are only used by gcc itself right? Why would you cross-compile these libraries? Cedric And everything went fine with just a couple of warnings: - during make check for the first 3 packages: libtool: warning: '-no-install' is ignored for aarch64-apple-darwin23.1.0 libtool: warning: assuming '-no-fast-install' instead - at the end of libisl make: ld: warning: -bind_at_load is deprecated on macOS warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: archive library: libdep.a the table of contents is empty (no object file members in the library define global symbols) So it seems that updating to the lastest packages would fix all outstanding M1 macOS issues witout any extra patches needed. Thanks for taking the time to do this testing. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [RSB PATCH] 6: Merge the MacOS M silicon patch from gcc-12 to gcc-13
On 27/11/2023 6:43 pm, Cedric Berger wrote: > I just installed the following packages successively: > > - https://gmplib.org/download/gmp/gmp-6.3.0.tar.xz > - https://www.mpfr.org/mpfr-current/mpfr-4.2.1.tar.gz This URL is not suitable so the GNU mirror is better. A change in version means mpfr-4.2.1.tar.gz is not accessible and that breaks our long term releases. I have hit this before and why we switched to downloading from gcc. > - https://ftp.gnu.org/gnu/mpc/mpc-1.3.1.tar.gz > - https://libisl.sourceforge.io/isl-0.26.tar.gz This does not build on my M2 with Sonoma and the latest Xcode. Something about a missing constructor. I tried 0.25 and it failed to detect the OS, which is the original issue we are wanting to solve. I will test 0.24 and the original patch. An update patch to 0.25 would be welcome if anyone is interested. I think we should add source-builder/config/gcc-13.cfg and then use ISL 0.24, MPFR 4.2.1, MPC 1.3.1 and GMP 6.3.0. I have built an aarch64 compiler without needing to disable the assembler in GMP. I will try some more architectures. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [RSB PATCH] 6: Merge the MacOS M silicon patch from gcc-12 to gcc-13
On 27/11/2023 6:43 pm, Cedric Berger wrote: > Hello, > > On 24.11.2023 08:36, Sebastian Huber wrote: >> Would updating to ISL 0.26 and MPC 1.3.1 fix this issue also? > > I just tried in on my fully up-to-date M1 Pro (macOS Sonoma 14.1.1, Xcode > 15.0.1) > > Short answer: everything works well without issues (configure, make, check) > > I just installed the following packages successively: > > - https://gmplib.org/download/gmp/gmp-6.3.0.tar.xz > - https://www.mpfr.org/mpfr-current/mpfr-4.2.1.tar.gz > - https://ftp.gnu.org/gnu/mpc/mpc-1.3.1.tar.gz > - https://libisl.sourceforge.io/isl-0.26.tar.gz > > by simply extracting the archive and doing: > > ./configure > make > make check > sudo make install Is this a native build? This seems to resolve the OS support part which is good however is the other issue of bad code execution in GMP fixed? This only showed up when the cross-compiled libraries are built? > And everything went fine with just a couple of warnings: > > - during make check for the first 3 packages: > > libtool: warning: '-no-install' is ignored for aarch64-apple-darwin23.1.0 > libtool: warning: assuming '-no-fast-install' instead > > - at the end of libisl make: > > ld: warning: -bind_at_load is deprecated on macOS > warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: archive > library: > libdep.a the table of contents is empty (no object file members in the library > define global symbols) > > So it seems that updating to the lastest packages would fix all outstanding M1 > macOS issues witout any extra patches needed. Thanks for taking the time to do this testing. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [RSB PATCH] 6: Merge the MacOS M silicon patch from gcc-12 to gcc-13
Hello, On 24.11.2023 08:36, Sebastian Huber wrote: Would updating to ISL 0.26 and MPC 1.3.1 fix this issue also? I just tried in on my fully up-to-date M1 Pro (macOS Sonoma 14.1.1, Xcode 15.0.1) Short answer: everything works well without issues (configure, make, check) I just installed the following packages successively: - https://gmplib.org/download/gmp/gmp-6.3.0.tar.xz - https://www.mpfr.org/mpfr-current/mpfr-4.2.1.tar.gz - https://ftp.gnu.org/gnu/mpc/mpc-1.3.1.tar.gz - https://libisl.sourceforge.io/isl-0.26.tar.gz by simply extracting the archive and doing: ./configure make make check sudo make install And everything went fine with just a couple of warnings: - during make check for the first 3 packages: libtool: warning: '-no-install' is ignored for aarch64-apple-darwin23.1.0 libtool: warning: assuming '-no-fast-install' instead - at the end of libisl make: ld: warning: -bind_at_load is deprecated on macOS warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: archive library: libdep.a the table of contents is empty (no object file members in the library define global symbols) So it seems that updating to the lastest packages would fix all outstanding M1 macOS issues witout any extra patches needed. Cedric ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [RSB PATCH] 6: Merge the MacOS M silicon patch from gcc-12 to gcc-13
On 24.11.23 05:36, chr...@rtems.org wrote:
From: Chris Johns
Updates #4921
---
rtems/config/tools/rtems-gcc-13.2-newlib-head.cfg | 14 ++
1 file changed, 14 insertions(+)
diff --git a/rtems/config/tools/rtems-gcc-13.2-newlib-head.cfg
b/rtems/config/tools/rtems-gcc-13.2-newlib-head.cfg
index 86e0135..4422e36 100644
--- a/rtems/config/tools/rtems-gcc-13.2-newlib-head.cfg
+++ b/rtems/config/tools/rtems-gcc-13.2-newlib-head.cfg
@@ -6,6 +6,20 @@
%hash sha512 gcc-%{gcc_version}.tar.xz \
2Z5IJqcNsEUERn40np+67apYcHZs2nxcq1DN6+3EvnVevKW3ieEjKjSiC+GgtgCX3pKA7+R723HHMlHjCwhiog==
+# Following patches are related to compilation on Apple M1/Darwin host platform.
+# They are here to workaround issues with ISL and MPC libraries.
+# Upstream projects were already informed so hopefully when RSB moves
+# to more modern libraries versions they may be removed from here.
+# The patches are solely for libisl 0.24 and libmpc 1.2.1
+# See #4657 for more information.
+%patch add isl
-p1https://devel.rtems.org/raw-attachment/ticket/4657/fix-mac-arm64-isl-config.patch
+%hash sha512 fix-mac-arm64-isl-config.patch \
+
wH/bYFplINGUNYUEcx5jtUAhHvaAOD8cpOxltKxDridodTT9fYGWpNvoOg7PLEKkJUxx5gnuSEp2FFc7xJmi6A==
+%patch add mpc
-p1https://devel.rtems.org/raw-attachment/ticket/4657/fix-mac-arm64-mpc-config.patch
+%hash sha512 fix-mac-arm64-mpc-config.patch \
+
KEmxHjYOqY4LTXCMZ3I60tbHusbR5GlnP0CLARHPAnhCnovDj9K3U43C1bsMxDDGRqD6fwtrEFoEgqVFX63IuQ==
+# Comment above related to #4657 and patches ends here
+
%define newlib_version 3cacedb
%define newlib_external 1
%define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
Would updating to ISL 0.26 and MPC 1.3.1 fix this issue also?
--
embedded brains GmbH
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
[RSB PATCH] 6: Merge the MacOS M silicon patch from gcc-12 to gcc-13
From: Chris Johns
Updates #4921
---
rtems/config/tools/rtems-gcc-13.2-newlib-head.cfg | 14 ++
1 file changed, 14 insertions(+)
diff --git a/rtems/config/tools/rtems-gcc-13.2-newlib-head.cfg
b/rtems/config/tools/rtems-gcc-13.2-newlib-head.cfg
index 86e0135..4422e36 100644
--- a/rtems/config/tools/rtems-gcc-13.2-newlib-head.cfg
+++ b/rtems/config/tools/rtems-gcc-13.2-newlib-head.cfg
@@ -6,6 +6,20 @@
%hash sha512 gcc-%{gcc_version}.tar.xz \
2Z5IJqcNsEUERn40np+67apYcHZs2nxcq1DN6+3EvnVevKW3ieEjKjSiC+GgtgCX3pKA7+R723HHMlHjCwhiog==
+# Following patches are related to compilation on Apple M1/Darwin host
platform.
+# They are here to workaround issues with ISL and MPC libraries.
+# Upstream projects were already informed so hopefully when RSB moves
+# to more modern libraries versions they may be removed from here.
+# The patches are solely for libisl 0.24 and libmpc 1.2.1
+# See #4657 for more information.
+%patch add isl -p1
https://devel.rtems.org/raw-attachment/ticket/4657/fix-mac-arm64-isl-config.patch
+%hash sha512 fix-mac-arm64-isl-config.patch \
+
wH/bYFplINGUNYUEcx5jtUAhHvaAOD8cpOxltKxDridodTT9fYGWpNvoOg7PLEKkJUxx5gnuSEp2FFc7xJmi6A==
+%patch add mpc -p1
https://devel.rtems.org/raw-attachment/ticket/4657/fix-mac-arm64-mpc-config.patch
+%hash sha512 fix-mac-arm64-mpc-config.patch \
+
KEmxHjYOqY4LTXCMZ3I60tbHusbR5GlnP0CLARHPAnhCnovDj9K3U43C1bsMxDDGRqD6fwtrEFoEgqVFX63IuQ==
+# Comment above related to #4657 and patches ends here
+
%define newlib_version 3cacedb
%define newlib_external 1
%define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
--
2.39.3 (Apple Git-145)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
