Building RTEMS 6 toolchain on a Mac

Cedric Berger cedric at precidata.com
Fri Apr 22 11:51:51 UTC 2022 

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
>
>
>
> ------------------------------------------------------------------------------
> Fritz-Haber-Institut    | Phone:         (+49 30) 8413-4270
> Heinz Junkes             | Fax (G3+G4):   (+49 30) 8413-5900
> Faradayweg 4-6        | VC: 102220181216 at bjn.vc
> D - 14195 Berlin        | E-Mail:        junkes at fhi-berlin.mpg.de
> ------------------------------------------------------------------------------
>
>> On 22. Apr 2022, at 08:55, Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
>>
>> 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.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

More information about the devel mailing list