Re: Building RTEMS 6 toolchain on a Mac
Hallo Sebastian, maybe too late, but this is the result of RTEMS 7 rsb on my Mac: Command Line: ../source-builder/sb-set-builder --jobs=4 --prefix=/Users/heinz/VE/ARM_WORK/rtems/7 7/rtems-arm Python: 3.8.5 (default, Sep 4 2020, 02:22:02) [Clang 10.0.0 ] https://github.com/RTEMS/rtems-source-builder.git/origin/a53d2c94322ed4fe261ba0c99bfb66a6cbd1def1 ... CXXunittests/tui-selftests.o In file included from ../../sourceware-mirror-binutils-gdb-36b1241/gdb/unittests/string_view-selftests.c:34: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/fstream:579:17: warning: The symbol ::fdopen refers to the system function. Use gnulib::fdopen instead. [-Wuser-defined-warnings] __file_ = fdopen(__fd, __mdstr); ^ ../gnulib/import/stdio.h:826:1: note: from 'diagnose_if' attribute on 'fdopen': _GL_CXXALIASWARN (fdopen); ^ ../gnulib/import/stdio.h:461:4: note: expanded from macro '_GL_CXXALIASWARN' _GL_CXXALIASWARN_1 (func, GNULIB_NAMESPACE) ^~~ ../gnulib/import/stdio.h:463:4: note: expanded from macro '_GL_CXXALIASWARN_1' _GL_CXXALIASWARN_2 (func, namespace) ^~~~ ../gnulib/import/stdio.h:468:5: note: expanded from macro '_GL_CXXALIASWARN_2' _GL_WARN_ON_USE (func, \ ^~~~ ../gnulib/import/stdio.h:632:19: note: expanded from macro '_GL_WARN_ON_USE' __attribute__ ((__diagnose_if__ (1, message, "warning"))) ^~ CXXunittests/ui-file-selftests.o CXXunittests/unique_xmalloc_ptr_char.o CXXunittests/unpack-selftests.o 1 warning generated. CXXunittests/utils-selftests.o CXXunittests/vec-utils-selftests.o CXXunittests/xml-utils-selftests.o CXXuser-regs.o CXXutils.o CXXvalarith.o CXXvalops.o CXXvalprint.o CXXvalue.o CXXvarobj.o GENstamp-version GENxml-builtin.c CXXxml-support.o CXXxml-syscall.o CXXxml-tdesc.o GENinit.c CXXgdb.o CXXaarch32-tdep.o CXXada-exp.o CXXada-lang.o CXXada-tasks.o CXXada-typeprint.o CXXada-valprint.o CXXada-varobj.o CXXaddrmap.o CXXagent.o CXXalloc.o CXXannotate.o CXXarch-utils.o CXXarch/aarch32.o CXXarch/arm-get-next-pcs.o CXXarch/arm.o CXXarm-none-tdep.o CXXarm-pikeos-tdep.o CXXarm-tdep.o CXXasync-event.o CXXauto-load.o CXXauxv.o CXXax-gdb.o CXXax-general.o CXXbcache.o CXXbfd-target.o CXXblock.o CXXblockframe.o CXXbreak-catch-exec.o CXXbreak-catch-fork.o CXXbreak-catch-sig.o CXXbreak-catch-syscall.o CXXbreak-catch-throw.o CXXbreakpoint.o CXXbt-utils.o CXXbtrace.o CXXbuild-id.o CXXbuildsym-legacy.o CXXbuildsym.o CXXc-exp.o CXXc-lang.o CXXc-typeprint.o CXXc-valprint.o CXXc-varobj.o CXXcharset.o CXXcli-out.o CXXcli/cli-cmds.o CXXcli/cli-decode.o CXXcli/cli-dump.o CXXcli/cli-interp.o CXXcli/cli-logging.o CXXcli/cli-option.o CXXcli/cli-script.o CXXcli/cli-setshow.o CXXcli/cli-style.o CXXcli/cli-utils.o CXXcoff-pe-read.o CXXcoffread.o CXXcompile/compile-c-support.o CXXcompile/compile-c-symbols.o CXXcompile/compile-c-types.o CXXcompile/compile-cplus-symbols.o CXXcompile/compile-cplus-types.o CXXcompile/compile-loc2c.o CXXcompile/compile-object-load.o CXXcompile/compile-object-run.o CXXcompile/compile.o CXXcomplaints.o CXXcompleter.o CXXcopying.o CXXcorefile.o CXXcorelow.o CXXcp-abi.o CXXcp-name-parser.o CXXcp-namespace.o CXXcp-support.o CXXcp-valprint.o CXXctfread.o CXXd-exp.o CXXf-exp.o CXXm2-exp.o CXXgo-exp.o In file included from ../../sourceware-mirror-binutils-gdb-36b1241/gdb/m2-exp.y:42: In file included from ../../sourceware-mirror-binutils-gdb-36b1241/gdb/language.h:26: In file included from ../../sourceware-mirror-binutils-gdb-36b1241/gdb/symtab.h:39: ../../sourceware-mirror-binutils-gdb-36b1241/gdb/split-name.h:34:3: error: expected identifier DOT, ^ m2-exp.c:163:13: note: expanded from macro 'DOT' #define DOT 302 ^ In file included from ../../sourceware-mirror-binutils-gdb-36b1241/gdb/m2-exp.y:42: In file included from ../../sourceware-mirror-binutils-gdb-36b1241/gdb/language.h:26: ../../sourceware-mirror-binutils-gdb-36b1241/gdb/symtab.h:306:23: error: expected unqualified-id style = split_style::DOT; ^ m2-exp.c:163:13: note: expanded from macro 'DOT' #define DOT 302 ^ 2 errors generated. make[2]: *** [m2-exp.o] Error 1 make[2]: *** Waiting for unfinished jobs
Re: Building RTEMS 6 toolchain on a Mac
On 4/27/22 08:48, Sebastian Huber wrote: On 27.04.22 08:45, Karel Gardas wrote: On 4/27/22 06:46, Sebastian Huber wrote: On 26.04.22 22:57, Karel Gardas wrote: On 4/25/22 10:10, Sebastian Huber wrote: Hello Heinz, you are probably one of the first persons building GCC 12 on this platform. I checked in a change which could fix the problem. Not sure if this is related, but after this hacking I'm no longer able to build neither 6/rtems-arm not 6/rtems-x86_64. I changed the mpfr version from 3.1.4 to 4.1.0. This is the latest mpfr release and used by the GCC contrib/download_prerequisites script currently. If this version doesn't build on macOS, then it would be good to submit a bug report to mpfr. The problem is that I'm perfectly able to build 4.1.0 including testsuite including its run on catalina. So the problem is somewhere else and rsb logging was just misleading... The RTEMS 7 RSB configuration still uses mpfr-4.1.0 (and GCC 12), maybe you can check it here. I'm a little bit confused since HEAD works fine with 7/rtems-arm and 7/rtems-x86_64 on catalina. So I reverted patches up to: me@mes-MacBook-Pro rtems % git log -1 commit 70f302e08c9053637f5eff7dfb52d3442aaf76cb (HEAD) Author: Chris Johns Date: Tue Apr 26 10:13:41 2022 +1000 gdb: Split python's version into major/minor and check for embed option Closes #4631 and now, 6/rtems-x86_64 correctly fails as I reported, but 7/rtems-x86_64 builds fine again. Diffing shows quite major differences between rtems-default.bset files for 6/ and 7/ so I guess that's the reason... Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Building RTEMS 6 toolchain on a Mac
On 27.04.22 08:45, Karel Gardas wrote: On 4/27/22 06:46, Sebastian Huber wrote: On 26.04.22 22:57, Karel Gardas wrote: On 4/25/22 10:10, Sebastian Huber wrote: Hello Heinz, you are probably one of the first persons building GCC 12 on this platform. I checked in a change which could fix the problem. Not sure if this is related, but after this hacking I'm no longer able to build neither 6/rtems-arm not 6/rtems-x86_64. I changed the mpfr version from 3.1.4 to 4.1.0. This is the latest mpfr release and used by the GCC contrib/download_prerequisites script currently. If this version doesn't build on macOS, then it would be good to submit a bug report to mpfr. The problem is that I'm perfectly able to build 4.1.0 including testsuite including its run on catalina. So the problem is somewhere else and rsb logging was just misleading... The RTEMS 7 RSB configuration still uses mpfr-4.1.0 (and GCC 12), maybe you can check it here. -- 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
Re: Building RTEMS 6 toolchain on a Mac
On 4/27/22 06:46, Sebastian Huber wrote: On 26.04.22 22:57, Karel Gardas wrote: On 4/25/22 10:10, Sebastian Huber wrote: Hello Heinz, you are probably one of the first persons building GCC 12 on this platform. I checked in a change which could fix the problem. Not sure if this is related, but after this hacking I'm no longer able to build neither 6/rtems-arm not 6/rtems-x86_64. I changed the mpfr version from 3.1.4 to 4.1.0. This is the latest mpfr release and used by the GCC contrib/download_prerequisites script currently. If this version doesn't build on macOS, then it would be good to submit a bug report to mpfr. The problem is that I'm perfectly able to build 4.1.0 including testsuite including its run on catalina. So the problem is somewhere else and rsb logging was just misleading... Karel Testsuite summary for MPFR 4.1.0 # TOTAL: 183 # PASS: 180 # SKIP: 3 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 [tversion] MPFR 4.1.0 [tversion] Compiler: Apple LLVM 12.0.0 (clang-1200.0.32.29) [tversion] C standard: __STDC__ = 1, __STDC_VERSION__ = 201112L [tversion] __GNUC__ = 4, __GNUC_MINOR__ = 2 [tversion] GMP: header 6.2.1, library 6.2.1 [tversion] __GMP_CC = "gcc" [tversion] __GMP_CFLAGS = "-O2 -pedantic -fomit-frame-pointer -m64 -mtune=sandybridge -march=sandybridge" [tversion] WinDLL: __GMP_LIBGMP_DLL = 0, MPFR_WIN_THREAD_SAFE_DLL = undef [tversion] MPFR_ALLOCA_MAX = 16384 [tversion] TLS = yes, float128 = no, decimal = no, GMP internals = no [tversion] Shared cache = no [tversion] intmax_t = yes, printf = yes, IEEE floats = yes [tversion] gmp_printf: hhd = yes, lld = yes, jd = yes, td = yes, Ld = yes [tversion] _mulx_u64 = no [tversion] MPFR tuning parameters from src/x86_64/mparam.h [tversion] sizeof(long) = 8, sizeof(mpfr_intmax_t) = 8, sizeof(intmax_t) = 8 [tversion] GMP_NUMB_BITS = 64, sizeof(mp_limb_t) = 8 [tversion] Within limb: long = y/y, intmax_t = y/y [tversion] _MPFR_PREC_FORMAT = 3, sizeof(mpfr_prec_t) = 8 [tversion] _MPFR_EXP_FORMAT = 3, sizeof(mpfr_exp_t) = 8 [tversion] sizeof(mpfr_t) = 32, sizeof(mpfr_ptr) = 8 [tversion] Precision range: [1,9223372036854775551] [tversion] Max exponent range: [-4611686018427387903,4611686018427387903] [tversion] Generic ABI code: no [tversion] Enable formally proven code: no [tversion] Locale: en_US.UTF-8 Making check in tune make[1]: Nothing to be done for `check'. Making check in tools/bench make[1]: Nothing to be done for `check'. make[1]: Nothing to be done for `check-am'. me@mes-MacBook-Pro mpfr-4.1.0 % ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Building RTEMS 6 toolchain on a Mac
On 27.04.22 07:46, Karel Gardas wrote: On 4/27/22 06:46, Sebastian Huber wrote: On 26.04.22 22:57, Karel Gardas wrote: On 4/25/22 10:10, Sebastian Huber wrote: Hello Heinz, you are probably one of the first persons building GCC 12 on this platform. I checked in a change which could fix the problem. Not sure if this is related, but after this hacking I'm no longer able to build neither 6/rtems-arm not 6/rtems-x86_64. I changed the mpfr version from 3.1.4 to 4.1.0. This is the latest mpfr release and used by the GCC contrib/download_prerequisites script currently. If this version doesn't build on macOS, then it would be good to submit a bug report to mpfr. Right. My build with: commit 6cf31074fa51c44ec563478b026a3778f5f214be Author: Sebastian Huber Date: Fri Apr 22 08:45:21 2022 +0200 6/7: Update GCC prerequisites for GCC 10 and 12 reverted went fine on catalina. Could you please test with the latest RSB. I changed it to use mpfr-3.1.6. -- 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
Re: Building RTEMS 6 toolchain on a Mac
On 27/4/2022 3:18 pm, Sebastian Huber wrote: > On 27.04.22 06:51, Chris Johns wrote: >> On 27/4/2022 2:46 pm, Sebastian Huber wrote: >>> On 26.04.22 22:57, Karel Gardas wrote: On 4/25/22 10:10, Sebastian Huber wrote: > Hello Heinz, > > you are probably one of the first persons building GCC 12 on this > platform. I > checked in a change which could fix the problem. > Not sure if this is related, but after this hacking I'm no longer able to build neither 6/rtems-arm not 6/rtems-x86_64. >>> I changed the mpfr version from 3.1.4 to 4.1.0. This is the latest mpfr >>> release >>> and used by the GCC contrib/download_prerequisites script currently. If this >>> version doesn't build on macOS, then it would be good to submit a bug >>> report to >>> mpfr. >> Can we please revert to 3.1.4 while this is resolved? > > Yes, of course, Thanks > but I will not work on bug reports or fixes for macOS. That is fine and understood. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Building RTEMS 6 toolchain on a Mac
On 4/27/22 06:46, Sebastian Huber wrote: On 26.04.22 22:57, Karel Gardas wrote: On 4/25/22 10:10, Sebastian Huber wrote: Hello Heinz, you are probably one of the first persons building GCC 12 on this platform. I checked in a change which could fix the problem. Not sure if this is related, but after this hacking I'm no longer able to build neither 6/rtems-arm not 6/rtems-x86_64. I changed the mpfr version from 3.1.4 to 4.1.0. This is the latest mpfr release and used by the GCC contrib/download_prerequisites script currently. If this version doesn't build on macOS, then it would be good to submit a bug report to mpfr. Right. My build with: commit 6cf31074fa51c44ec563478b026a3778f5f214be Author: Sebastian Huber Date: Fri Apr 22 08:45:21 2022 +0200 6/7: Update GCC prerequisites for GCC 10 and 12 reverted went fine on catalina. Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Building RTEMS 6 toolchain on a Mac
On 27.04.22 06:51, Chris Johns wrote: On 27/4/2022 2:46 pm, Sebastian Huber wrote: On 26.04.22 22:57, Karel Gardas wrote: On 4/25/22 10:10, Sebastian Huber wrote: Hello Heinz, you are probably one of the first persons building GCC 12 on this platform. I checked in a change which could fix the problem. Not sure if this is related, but after this hacking I'm no longer able to build neither 6/rtems-arm not 6/rtems-x86_64. I changed the mpfr version from 3.1.4 to 4.1.0. This is the latest mpfr release and used by the GCC contrib/download_prerequisites script currently. If this version doesn't build on macOS, then it would be good to submit a bug report to mpfr. Can we please revert to 3.1.4 while this is resolved? Yes, of course, but I will not work on bug reports or fixes for macOS. -- 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
Re: Building RTEMS 6 toolchain on a Mac
On 27/4/2022 2:46 pm, Sebastian Huber wrote: > On 26.04.22 22:57, Karel Gardas wrote: >> On 4/25/22 10:10, Sebastian Huber wrote: >>> Hello Heinz, >>> >>> you are probably one of the first persons building GCC 12 on this platform. >>> I >>> checked in a change which could fix the problem. >>> >> >> Not sure if this is related, but after this hacking I'm no longer able to >> build neither 6/rtems-arm not 6/rtems-x86_64. > > I changed the mpfr version from 3.1.4 to 4.1.0. This is the latest mpfr > release > and used by the GCC contrib/download_prerequisites script currently. If this > version doesn't build on macOS, then it would be good to submit a bug report > to > mpfr. Can we please revert to 3.1.4 while this is resolved? Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Building RTEMS 6 toolchain on a Mac
On 26.04.22 22:57, Karel Gardas wrote: On 4/25/22 10:10, Sebastian Huber wrote: Hello Heinz, you are probably one of the first persons building GCC 12 on this platform. I checked in a change which could fix the problem. Not sure if this is related, but after this hacking I'm no longer able to build neither 6/rtems-arm not 6/rtems-x86_64. I changed the mpfr version from 3.1.4 to 4.1.0. This is the latest mpfr release and used by the GCC contrib/download_prerequisites script currently. If this version doesn't build on macOS, then it would be good to submit a bug report to mpfr. -- 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
Re: Building RTEMS 6 toolchain on a Mac
On 4/25/22 10:10, Sebastian Huber wrote: Hello Heinz, you are probably one of the first persons building GCC 12 on this platform. I checked in a change which could fix the problem. Not sure if this is related, but after this hacking I'm no longer able to build neither 6/rtems-arm not 6/rtems-x86_64. Both fail with: abs_ui.o get_patches.o /Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libmpfr.a(volatile.o) has no symbols /Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libmpfr.a(logging.o) has no symbols /Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libmpfr.a(set_d64.o) has no symbols /Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libmpfr.a(get_d64.o) has no symbols /Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libmpfr.a(set_float128.o) has no symbols /Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libmpfr.a(get_float128.o) has no symbols /Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libmpfr.a(mpfr-mini-gmp.o) has no symbols /Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libmpfr.a(set_d128.o) has no symbols /Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libmpfr.a(get_d128.o) has no symbols libtool: link: ranlib .libs/libmpfr.a /Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libmpfr.a(volatile.o) has no symbols /Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libmpfr.a(logging.o) has no symbols /Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libmpfr.a(set_d64.o) has no symbols /Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libmpfr.a(get_d64.o) has no symbols /Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libmpfr.a(set_float128.o) has no symbols /Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libmpfr.a(get_float128.o) has no symbols /Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libmpfr.a(mpfr-mini-gmp.o) has no symbols /Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libmpfr.a(set_d128.o) has no symbols /Library/Developer/CommandLineTools/usr/bin/ranlib: file: .libs/libmpfr.a(get_d128.o) has no symbols libtool: link: ( cd ".libs" && rm -f "libmpfr.la" && ln -s "../libmpfr.la" "libmpfr.la" ) Making all in tests make[3]: Nothing to be done for `all'. Making all in tune make[3]: Nothing to be done for `all'. Making all in tools/bench make[3]: Nothing to be done for `all'. make[3]: Nothing to be done for `all-am'. make: *** [all] Error 2 shell cmd failed: /bin/sh -ex /Users/me/git/workspace/rtems-source-builder/rtems/build/arm-rtems6-gcc-0f001dd-newlib-64b2081-x86_64-apple-darwin19.6.0-1/do-build error: building arm-rtems6-gcc-0f001dd-newlib-64b2081-x86_64-apple-darwin19.6.0-1 Thanks, Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Building RTEMS 6 toolchain on a Mac
Hello Heinz, you are probably one of the first persons building GCC 12 on this platform. I checked in a change which could fix the problem. -- 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
Re: Building RTEMS 6 toolchain on a Mac
Hello Sebastian, unfortunately I could not build rtems7 on the Mac (as I can for rtems6): Cloning into 'rsb'... RTEMS Source Builder - Set Builder, 6 (376bf3247498) Build Set: 7/rtems-arm config: devel/dtc-1.6.1-1.cfg package: dtc-1.6.1-x86_64-apple-darwin21.4.0-1 Creating source directory: sources download: https://www.kernel.org/pub/software/utils/dtc/dtc-1.6.1.tar.gz -> sources/dtc-1.6.1.tar.gz redirect: https://mirrors.edge.kernel.org/pub/software/utils/dtc/dtc-1.6.1.tar.gz ^Mdownloading: sources/dtc-1.6.1.tar.gz - 0.0 bytes of 199.0kB (0%) ^Mdownloading: sources/dtc-1.6.1.tar.gz - 199.0kB of 199.0kB (100%) ^Mbuilding: dtc-1.6.1-x86_64-apple-darwin21.4.0-1 sizes: dtc-1.6.1-x86_64-apple-darwin21.4.0-1: 4.504MB (installed: 814.811KB) cleaning: dtc-1.6.1-x86_64-apple-darwin21.4.0-1 reporting: devel/dtc-1.6.1-1.cfg -> dtc-1.6.1-x86_64-apple-darwin21.4.0-1.txt reporting: devel/dtc-1.6.1-1.cfg -> dtc-1.6.1-x86_64-apple-darwin21.4.0-1.xml config: devel/expat-2.1.0-1.cfg package: expat-2.1.0-x86_64-apple-darwin21.4.0-1 download: https://github.com/libexpat/libexpat/releases/download/R_2_1_0/expat-2.1.0.tar.gz -> sources/expat-2.1.0.tar.gz … ownloading: sources/gmp-6.2.1.tar.bz2 - 1.8MB of 2.4MB (74%) ^Mdownloading: sources/gmp-6.2. 1.tar.bz2 - 2.0MB of 2.4MB (84%) ^Mdownloading: sources/gmp-6.2.1.tar.bz2 - 2.2MB of 2.4MB ( 95%) ^Mdownloading: sources/gmp-6.2.1.tar.bz2 - 2.4MB of 2.4MB (100%) ^Mbuilding: arm-rtems7-gcc-b6e3390-newlib-64b2081-x86_64-apple-darwin21.4.0-1 error: building arm-rtems7-gcc-b6e3390-newlib-64b2081-x86_64-apple-darwin21.4.0-1 Build FAILED See error report: rsb-report-arm-rtems7-gcc-b6e3390-newlib-64b2081-x86_64-apple-darwin21.4 .0-1.txt error: building arm-rtems7-gcc-b6e3390-newlib-64b2081-x86_64-apple-darwin21.4.0-1 Build Set: Time 0:12:11.609355 Build FAILED … libtool: compile: /usr/bin/cc -O2 -pipe -fbracket-depth=1024 -I/Users/heinz/VE/rsb/rtems/build/tmp/sb-502/7/rtems-arm/Users/heinz/VE/ARM_WORK/rtems/7/include -DHAVE_CONFIG_H -I. -I../../../gnu-mirror-gcc-b6e3390/gmp/mpn -I.. -D__GMP_WITHIN_GMP -I../../../gnu-mirror-gcc-b6e3390/gmp -DOPERATION_gcd_22 -DNO_ASM -g -O2 -c gcd_22.c -o gcd_22.o gcd_22.c:128:10: error: implicit declaration of function 'mpn_gcd_11' is invalid in C99 [-Werror,-Wimplicit-function-declaration] g.d0 = mpn_gcd_11 ((u0 << 1) + 1, (v0 << 1) + 1); ^ 1 error generated. make[4]: *** [gcd_22.lo] Error 1 make[4]: *** Waiting for unfinished jobs make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-gmp] Error 2 make: *** [all] Error 2 shell cmd failed: /bin/sh -ex /Users/heinz/VE/rsb/rtems/build/arm-rtems7-gcc-b6e3390-newlib-64b2081-x86_64-apple-darwin21.4.0-1/do-build error: building arm-rtems7-gcc-b6e3390-newlib-64b2081-x86_64-apple-darwin21.4.0-1(base) Gruss Heinz > On 22. Apr 2022, at 14:06, Sebastian Huber > wrote: > > On 22/04/2022 08:55, Sebastian Huber wrote: >>> Could GCC be upgraded to 11.2 or 12.0 which should be available very soon? >>> are the patches still needed? >> It is still undecided which GCC version will be used for RTEMS 6. GCC 10 >> will reach its end of life with the next release this year. GCC 12 would be >> brand new. We didn't use GCC 11 so far. I tend to use GCC 12. > > I checked in some updates for the RSB. Could you please check if you can > build the RTEMS 7 tool chain which is based on GCC 12: > > ../source-builder/sb-set-builder 7/rtems-arm > > -- > 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Building RTEMS 6 toolchain on a Mac
On 22/04/2022 08:55, Sebastian Huber wrote: Could GCC be upgraded to 11.2 or 12.0 which should be available very soon? are the patches still needed? It is still undecided which GCC version will be used for RTEMS 6. GCC 10 will reach its end of life with the next release this year. GCC 12 would be brand new. We didn't use GCC 11 so far. I tend to use GCC 12. I checked in some updates for the RSB. Could you please check if you can build the RTEMS 7 tool chain which is based on GCC 12: ../source-builder/sb-set-builder 7/rtems-arm -- 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
Re: Building RTEMS 6 toolchain on a Mac
Hmm, which version of clang do you have? are you up-to-date with XCode?
$ cc --version
Apple clang version 13.1.6 (clang-1316.0.21.2.3)
Target: arm64-apple-darwin21.4.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
Cedric
On 22.04.22 09:10, Heinz Junkes wrote:
I'm going to slip into the thread here.
I could successfully build rtems6 for arm on the M1 Mac yesterday evening.
git clone https://github.com/RTEMS/rtems-source-builder.git rsb
cd rsb
cd rtems
../source-builder/sb-set-builder --jobs=4 --prefix=${RTEMS_ROOT}
${RTEMS_VERSION}/rtems-arm
One problem I encountered was the building of the qemu (devel/qemu) on the Mac
(Monterey, 12.3.1 ):
RTEMS Source Builder - Set Builder, 6 (49e3dac17765)
Command Line: ../source-builder/sb-set-builder --jobs=4
--prefix=/Users/heinz/VE/ARM_WORK/rtems/6 devel/qemu
Python: 3.8.5 (default, Sep 4 2020, 02:22:02) [Clang 10.0.0 ]
Build Set: devel/qemu
Build Set: devel/autotools-internal.bset
config: devel/autoconf-2.69-1.cfg
package: autoconf-2.69-x86_64-apple-darwin21.4.0-1
….
/bin/sh ../libtool --tag=CC --mode=link /usr/bin/cc -O2 -pipe
-fbracket-depth=1024
-I/Users/heinz/VE/rsb/rtems/build/tmp/sb-502/devel/qemu/Users/heinz/VE/ARM_WORK/rtems/6/include
-g -O2 -no-undefined -liconv ../intl/libintl.la -liconv -Wl,-framework
-Wl,CoreFoundation -lunistring -Wl,-framework -Wl,CoreFoundation -release
0.18.3 -lcroco-0.6
-L/Users/heinz/VE/rsb/rtems/build/tmp/sb-502/devel/qemu/Users/heinz/VE/ARM_WORK/rtems/6/lib
-lglib-2.0
-L/Users/heinz/VE/rsb/rtems/build/tmp/sb-502/devel/qemu/Users/heinz/VE/ARM_WORK/rtems/6/lib
-lintl -liconv -lc
-R/Users/heinz/VE/rsb/rtems/build/tmp/sb-502/devel/qemu/Users/heinz/VE/ARM_WORK/rtems/6/lib
-L/Users/heinz/VE/rsb/rtems/build/tmp/sb-502/devel/qemu/Users/heinz/VE/ARM_WORK/rtems/6/lib
-lglib-2.0
-L/Users/heinz/VE/rsb/rtems/build/tmp/sb-502/devel/qemu/Users/heinz/VE/ARM_WORK/rtems/6/lib
-lintl -liconv -lc
-R/Users/heinz/VE/rsb/rtems/build/tmp/sb-502/devel/qemu/Users/heinz/VE/ARM_WORK/rtems/6/lib
-lxml2 -liconv -liconv -liconv -lncurses
-L/Users/heinz/VE/rsb/rtems/build/tmp/sb-502/devel/qemu/Users/heinz/VE/ARM_WORK/rtems/6/lib
-o libgettextlib.la -rpath /Users/heinz/VE/ARM_WORK/rtems/6/lib copy-acl.lo
set-acl.lo allocator.lo areadlink.lo argmatch.lo gl_array_list.lo backupfile.lo
addext.lo basename.lo binary-io.lo c-ctype.lo c-strcasecmp.lo c-strncasecmp.lo
c-strcasestr.lo c-strstr.lo careadlinkat.lo classpath.lo clean-temp.lo
cloexec.lo closeout.lo concat-filename.lo copy-file.lo csharpcomp.lo
csharpexec.lo error-progname.lo execute.lo exitfail.lo fatal-signal.lo
fd-hook.lo fd-ostream.lo fd-safer-flag.lo dup-safer-flag.lo file-ostream.lo
findprog.lo fstrcmp.lo full-write.lo fwriteerror.lo gcd.lo hash.lo
html-ostream.lo html-styled-ostream.lo javacomp.lo javaexec.lo javaversion.lo
gl_linkedhash_list.lo gl_list.lo localcharset.lo localename.lo glthread/lock.lo
malloca.lo mbchar.lo mbiter.lo mbslen.lo mbsstr.lo mbswidth.lo mbuiter.lo
ostream.lo pipe-filter-ii.lo pipe-filter-aux.lo pipe2.lo pipe2-safer.lo
progname.lo propername.lo acl-errno-valid.lo file-has-acl.lo qcopy-acl.lo
qset-acl.lo quotearg.lo safe-read.lo safe-write.lo sh-quote.lo sig-handler.lo
spawn-pipe.lo striconv.lo striconveh.lo striconveha.lo strnlen1.lo
styled-ostream.lo tempname.lo term-ostream.lo term-styled-ostream.lo
glthread/threadlib.lo glthread/tls.lo tmpdir.lo trim.lo unilbrk/lbrktables.lo
unilbrk/ulc-common.lo unistd.lo dup-safer.lo fd-safer.lo pipe-safer.lo
wait-process.lo wctype-h.lo xmalloc.lo xstrdup.lo xconcat-filename.lo
xerror.lo gl_xlist.lo xmalloca.lo xreadlink.lo xsetenv.lo xsize.lo xstriconv.lo
xstriconveh.lo xvasprintf.lo xasprintf.lo acl_entries.lo asnprintf.lo
canonicalize-lgpl.lo error.lo fnmatch.lo getopt.lo getopt1.lo lstat.lo
obstack.lo open.lo printf-args.lo printf-parse.lo rawmemchr.lo readlink.lo
secure_getenv.lo stat.lo strchrnul.lo strerror.lo strerror-override.lo
strstr.lo vasnprintf.lo wcwidth.lo
libtool: link: warning: library
`/Users/heinz/VE/rsb/rtems/build/tmp/sb-502/devel/qemu/Users/heinz/VE/ARM_WORK/rtems/6/lib/libglib-2.0.la'
was moved.
grep: /Users/heinz/VE/ARM_WORK/rtems/6/lib/libintl.la: No such file or directory
/usr/local/bin/gsed: can't read
/Users/heinz/VE/ARM_WORK/rtems/6/lib/libintl.la: No such file or directory
libtool: link: `/Users/heinz/VE/ARM_WORK/rtems/6/lib/libintl.la' is not a valid
libtool archive
make[4]: *** [libgettextlib.la] Error 1
make[3]: *** [all] Error 2
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1
shell cmd failed: /bin/sh -ex
/Users/heinz/VE/rsb/rtems/build/gettext-0.18.3.1-x86_64-apple-darwin21.4.0-1/do-build
error: building gettext-0.18.3.1-x86_64-apple-darwin21.4.0-1
See error report: rsb-report-gettext-0.18.3.1-x86_64-apple-darwin21.4.0-1.txt
Build Set: Time 0:04:14.522148
Gruss Heinz
Re: Building RTEMS 6 toolchain on a Mac
I'm going to slip into the thread here.
I could successfully build rtems6 for arm on the M1 Mac yesterday evening.
git clone https://github.com/RTEMS/rtems-source-builder.git rsb
cd rsb
cd rtems
../source-builder/sb-set-builder --jobs=4 --prefix=${RTEMS_ROOT}
${RTEMS_VERSION}/rtems-arm
One problem I encountered was the building of the qemu (devel/qemu) on the Mac
(Monterey, 12.3.1 ):
RTEMS Source Builder - Set Builder, 6 (49e3dac17765)
Command Line: ../source-builder/sb-set-builder --jobs=4
--prefix=/Users/heinz/VE/ARM_WORK/rtems/6 devel/qemu
Python: 3.8.5 (default, Sep 4 2020, 02:22:02) [Clang 10.0.0 ]
Build Set: devel/qemu
Build Set: devel/autotools-internal.bset
config: devel/autoconf-2.69-1.cfg
package: autoconf-2.69-x86_64-apple-darwin21.4.0-1
….
/bin/sh ../libtool --tag=CC --mode=link /usr/bin/cc -O2 -pipe
-fbracket-depth=1024
-I/Users/heinz/VE/rsb/rtems/build/tmp/sb-502/devel/qemu/Users/heinz/VE/ARM_WORK/rtems/6/include
-g -O2 -no-undefined -liconv ../intl/libintl.la -liconv -Wl,-framework
-Wl,CoreFoundation -lunistring -Wl,-framework -Wl,CoreFoundation -release
0.18.3 -lcroco-0.6
-L/Users/heinz/VE/rsb/rtems/build/tmp/sb-502/devel/qemu/Users/heinz/VE/ARM_WORK/rtems/6/lib
-lglib-2.0
-L/Users/heinz/VE/rsb/rtems/build/tmp/sb-502/devel/qemu/Users/heinz/VE/ARM_WORK/rtems/6/lib
-lintl -liconv -lc
-R/Users/heinz/VE/rsb/rtems/build/tmp/sb-502/devel/qemu/Users/heinz/VE/ARM_WORK/rtems/6/lib
-L/Users/heinz/VE/rsb/rtems/build/tmp/sb-502/devel/qemu/Users/heinz/VE/ARM_WORK/rtems/6/lib
-lglib-2.0
-L/Users/heinz/VE/rsb/rtems/build/tmp/sb-502/devel/qemu/Users/heinz/VE/ARM_WORK/rtems/6/lib
-lintl -liconv -lc
-R/Users/heinz/VE/rsb/rtems/build/tmp/sb-502/devel/qemu/Users/heinz/VE/ARM_WORK/rtems/6/lib
-lxml2 -liconv -liconv -liconv -lncurses
-L/Users/heinz/VE/rsb/rtems/build/tmp/sb-502/devel/qemu/Users/heinz/VE/ARM_WORK/rtems/6/lib
-o libgettextlib.la -rpath /Users/heinz/VE/ARM_WORK/rtems/6/lib copy-acl.lo
set-acl.lo allocator.lo areadlink.lo argmatch.lo gl_array_list.lo backupfile.lo
addext.lo basename.lo binary-io.lo c-ctype.lo c-strcasecmp.lo c-strncasecmp.lo
c-strcasestr.lo c-strstr.lo careadlinkat.lo classpath.lo clean-temp.lo
cloexec.lo closeout.lo concat-filename.lo copy-file.lo csharpcomp.lo
csharpexec.lo error-progname.lo execute.lo exitfail.lo fatal-signal.lo
fd-hook.lo fd-ostream.lo fd-safer-flag.lo dup-safer-flag.lo file-ostream.lo
findprog.lo fstrcmp.lo full-write.lo fwriteerror.lo gcd.lo hash.lo
html-ostream.lo html-styled-ostream.lo javacomp.lo javaexec.lo javaversion.lo
gl_linkedhash_list.lo gl_list.lo localcharset.lo localename.lo glthread/lock.lo
malloca.lo mbchar.lo mbiter.lo mbslen.lo mbsstr.lo mbswidth.lo mbuiter.lo
ostream.lo pipe-filter-ii.lo pipe-filter-aux.lo pipe2.lo pipe2-safer.lo
progname.lo propername.lo acl-errno-valid.lo file-has-acl.lo qcopy-acl.lo
qset-acl.lo quotearg.lo safe-read.lo safe-write.lo sh-quote.lo sig-handler.lo
spawn-pipe.lo striconv.lo striconveh.lo striconveha.lo strnlen1.lo
styled-ostream.lo tempname.lo term-ostream.lo term-styled-ostream.lo
glthread/threadlib.lo glthread/tls.lo tmpdir.lo trim.lo unilbrk/lbrktables.lo
unilbrk/ulc-common.lo unistd.lo dup-safer.lo fd-safer.lo pipe-safer.lo
wait-process.lo wctype-h.lo xmalloc.lo xstrdup.lo xconcat-filename.lo
xerror.lo gl_xlist.lo xmalloca.lo xreadlink.lo xsetenv.lo xsize.lo xstriconv.lo
xstriconveh.lo xvasprintf.lo xasprintf.lo acl_entries.lo asnprintf.lo
canonicalize-lgpl.lo error.lo fnmatch.lo getopt.lo getopt1.lo lstat.lo
obstack.lo open.lo printf-args.lo printf-parse.lo rawmemchr.lo readlink.lo
secure_getenv.lo stat.lo strchrnul.lo strerror.lo strerror-override.lo
strstr.lo vasnprintf.lo wcwidth.lo
libtool: link: warning: library
`/Users/heinz/VE/rsb/rtems/build/tmp/sb-502/devel/qemu/Users/heinz/VE/ARM_WORK/rtems/6/lib/libglib-2.0.la'
was moved.
grep: /Users/heinz/VE/ARM_WORK/rtems/6/lib/libintl.la: No such file or directory
/usr/local/bin/gsed: can't read
/Users/heinz/VE/ARM_WORK/rtems/6/lib/libintl.la: No such file or directory
libtool: link: `/Users/heinz/VE/ARM_WORK/rtems/6/lib/libintl.la' is not a valid
libtool archive
make[4]: *** [libgettextlib.la] Error 1
make[3]: *** [all] Error 2
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1
shell cmd failed: /bin/sh -ex
/Users/heinz/VE/rsb/rtems/build/gettext-0.18.3.1-x86_64-apple-darwin21.4.0-1/do-build
error: building gettext-0.18.3.1-x86_64-apple-darwin21.4.0-1
See error report: rsb-report-gettext-0.18.3.1-x86_64-apple-darwin21.4.0-1.txt
Build Set: Time 0:04:14.522148
Gruss Heinz
--
Fritz-Haber-Institut| Phone: (+49 30) 8413-4270
Heinz Junkes | Fax (G3+G4): (+49 30) 8413-5900
Faradayweg 4-6| VC: 102220181...@bjn.vc
D - 14195 Berlin| E-Mail:jun...@fhi-berlin.mpg.de
Re: Building RTEMS 6 toolchain on a Mac
On 18/04/2022 21:01, Cedric Berger wrote: Hello, On 11.04.22 00:37, Chris Johns wrote: I suspect we will need a later version of expat that has the aarch64 support. I do not have access access to an M1 Mac so I cannot test this. Chris So I tried to compile RTEMS 6 for arm on MacOS for both the M1 and Intel architecture. It was not very sucessful. Command: rtems# ../source-builder/sb-set-builder --prefix=/opt/data/workspace/rtems-tools 6/rtems-arm First on a M1 (fully patched and updated Mac Book Pro): I got the same failure as Jay Zhu with expat, but that was easy to fix: I can confirm that moving from expat 2.1.0 to expat 2.4.8 solve the problem. Next is the same issue with GMP. Again easy to fix by moving from gmp 6.1.0 to 6.2.1, which solves the problem. I sent a patch to update the GCC prerequisites to the versions in the latest gcc/contrib/download_prerequisites script for GCC 10 and 12. At this point everthing compiles fine up to and including binutils 2.38 The next problem however is with gcc, which fails the same way (machine `arm64-apple' not recognized) Fixing this however is above my pay grade: It seems RTEMS uses a patched, unreleased version of GCC. what to do? RTEMS follows the release branch of GCC. Some patches cannot be back ported to a GCC release branch in upstream GCC, so there may be some RTEMS-specific patches. In general, all RTEMS-specific changes are integrated in the GCC master. Next I tried on an Intel Mac (an older fully patched and updated Mac Book Pro): The build also failed compiling gcc, but with another error: clang: warning: argument unused during compilation: '-no-pie' [-Wunused-command-line-argument] Undefined symbols for architecture x86_64: "_arm_arch6", referenced from: __GLOBAL__sub_I_gencondmd.c in gencondmd.o "_arm_arch6m", referenced from: __GLOBAL__sub_I_gencondmd.c in gencondmd.o "_arm_arch7", referenced from: __GLOBAL__sub_I_gencondmd.c in gencondmd.o "_arm_arch8", referenced from: __GLOBAL__sub_I_gencondmd.c in gencondmd.o "_arm_arch_notm", referenced from: __GLOBAL__sub_I_gencondmd.c in gencondmd.o "_arm_arch_thumb2", referenced from: __GLOBAL__sub_I_gencondmd.c in gencondmd.o "_target_flags", referenced from: __GLOBAL__sub_I_gencondmd.c in gencondmd.o ld: symbol(s) not found for architecture x86_64 is this something like this? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92061#c5 If this is the same bug, then it is fixed on gcc 11.2 according to the last comment above. So what to do next? GCC fails on both Intel and M1 Mac, for different reasons. Could GCC be upgraded to 11.2 or 12.0 which should be available very soon? are the patches still needed? It is still undecided which GCC version will be used for RTEMS 6. GCC 10 will reach its end of life with the next release this year. GCC 12 would be brand new. We didn't use GCC 11 so far. I tend to use GCC 12. -- 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
