Cross-compile GCC für ARM64?

[goetz @ 3rz]

Hallo,

hat schon jemand einen GCC als universal binary für macOS gesehen, oder als arm64-Binary? Ich finde bei den drei Verdächtigen „nur“ ein Mach-O 64-bit executable x86_64, arm64e wäre schön.

[Thorsten Otto]

macOS benutzt eigentlich clang, und der ist eigentlich grundsätzlich ein cross-compiler. Problematisch dürfte eher sein:

- woher bekommt man cross-compilierte libraries für cocoa etc. auf den host?

- der ld den man für für macos braucht, ist nicht der aus den binutils. Tools wie otool zum linken von universal binaries sind meine ich nur für macOS verfügbar

[czietz]

Ich vermute, @gh-baden sucht (im Sinne dieses Forum) einen Crosscompiler für m68k, der nativ auf einem ARM-Mac läuft.

[Thorsten Otto]

Oh, eh ja, wahrscheinlich

Da ich kein macOS mit arm habe, müsstest du dir das wohl selber bauen

Kann da leider nur auf meine scripte verweisen: http://tho-otto.de/download/mint/binutils-2.39-20220911-build.sh und http://tho-otto.de/download/mint/gcc-4.6.4-20200502-build.sh (für gcc 4.6.4) bzw. eins der anderen scripte für neuere gcc versionen.

Auf jeden Fall brauchst du erstmal die binutils, ich würde also damit anfangen. Für arm werden wohl auch Anpassungen notwendig sein, auch die Pfade musst du prüfen.

Zum testen ist es vermutlich am einfachsten, die entsprechenden Repos zu clonen (https://github.com/th-otto/binutils.git, branch binutils-2_39-mint und https://github.com/th-otto/m68k-atari-mint-gcc.git, branch mint/gcc-4.6 oder entsprechend andere Versionen). Ohne die repos müssten sonst immer erst die tar archive entpackt, und der patch angewandt werden.

[Thorsten Otto]

Hab jetzt tatsächlich mal versucht macOS Monterey unter VirtualBox zum laufen zu bekommen. Hat auch weitgehend funktioniert. Allerdings ist alles extrem zäh. Dann wollte ich die commandline-tools installieren. Resultat siehe Bild. Da habe ich es drann dran gegeben

[goetz @ 3rz]

Hab jetzt tatsächlich mal versucht macOS Monterey unter VirtualBox zum laufen zu bekommen. Hat auch weitgehend funktioniert. Allerdings ist alles extrem zäh. Dann wollte ich die commandline-tools installieren. Resultat siehe Bild. Da habe ich es drann dran gegeben

Ich hab die passende Hardware, aber mangelnde Kenntnisse. Ich habe dein binutils-Zweig mit git clone --recursive in ein Verzeichnis kopiert, das binutils-2.39-20220911-build.sh Script in ein Verzeichnis darüber, dann das durch git neu entstandene Verzeichnis binutils mit einem Synlink binutils-2.39 ergänzt, da das Script wohl danach sucht:

Code: [Auswählen]

% bash binutils-2.39-20220911-build.sh
binutils-2.39: no such directory

Mit dem Symlink war der Fehler weg, nun fehlen noch die Patches. Also die gezogen und …

Code: [Auswählen]

% patch patches/binutils/*
patching file 'patches/binutils/binutils-2.39-mint-20220911.patch'
1 out of 1 hunks failed--saving rejects to 'patches/binutils/binutils-2.39-mint-20220911.patch.rej'

… mit …

Code: [Auswählen]

@@ -30,7 +30,7 @@
                     const bfd_arch_info_type *b);

 #define N(name, print,d,next)  \
-{  32, 32, 8, bfd_arch_m68k, name, "m68k",print,2,d,bfd_m68k_compatible, \
+{  32, 32, 8, bfd_arch_m68k, name, "m68k",print,1,d,bfd_m68k_compatible, \
    bfd_default_scan, bfd_arch_default_fill, next, 0 }

 static const bfd_arch_info_type arch_info_struct[] =

Was mache ich falsch?

Meine Umgebung:

Code: [Auswählen]

% clang -v
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: arm64-apple-darwin22.3.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin


Code: [Auswählen]

% sw_vers
ProductName: macOS
ProductVersion: 13.2
BuildVersion: 22D49


[Thorsten Otto]

Was mache ich falsch?

Wie Du an der Meldung

patching file 'patches/binutils/binutils-2.39-mint-20220911.patch'

siehst, versuchst du gerade den patch zu patchen

Allerdings: wenn du das Directory mit git gecloned hast, brauchst du den patch nicht. Du musst dann allerdings auch den richtigen branch auschecken:

Code: [Auswählen]

$ cd <pfad-zu>/binutils
$ git checkout binutils-2_39-mint

Dann wieder in das Verzeichnis wo das script ist, und du die Sachen bauen willst (kann auch ganz woanders sein), und dort ein

Code: [Auswählen]

$ touch .patched-binutils-2.39

damit er weiss daß er nicht mehr patchen muss.

Dann sollte es hoffentlich gehen.

Entsprechendes gilt auch später für gcc:

Code: [Auswählen]

$ cd <pfad-wo-gcc-gecloned ist>
$ git checkout mint/gcc-4.6
$ cd <pfad-zu-build-directory>
$ touch .patched-gcc-4.6.4
$ ./gcc-4.6.4-20200502-build.sh

PS: ja, ich weiss, da sollten im script ein paar mehr Kommentare stehen

[Thorsten Otto]

Wenn mans nicht selber bauen kann, lässt man halt bauen (in dem Fall von github)

Kannst du mal http://tho-otto.de/snapshots/crossmint/macos/binutils/binutils-2.39-mint-20220911-bin-macos.tar.xz testen?

Hatte erst ein paar Probleme. Obwohl da monterey läuft behauptet er steif und fest, das wäre ein x64-64 System. Was liefert bei dir

Code: [Auswählen]

$ uname -m
$ clang --print-target-triple

gcc muss ich noch schauen. Könnte etwas schwieriger werden, vor allem bei den zusätzlichen libraries (gmp, mpfr, und mpc). Sind die bei dir schon universal? (bzw überhaupt vorhanden als *.dylib)? Ansonsten muss ich schauen daß die statisch gebaut werden, allerdings sind die eigentlich per target angepasst.

[czietz]

Hatte erst ein paar Probleme. Obwohl da monterey läuft behauptet er steif und fest, das wäre ein x64-64 System.

Das dürfte daran liegen, dass es eben ein x86-64-System ist! MacOS-Runner auf ARM64 hat GitHub für das dritten Quartal 2023 auf der Roadmap: https://github.com/orgs/github/projects/4247/views/1?filterQuery=status%3A%22Q3+2023+%E2%80%93+Jul-Sep%22.

[goetz @ 3rz]

Wenn mans nicht selber bauen kann, lässt man halt bauen (in dem Fall von github)

Bist schneller als ich   

Sieht gut aus:

Code: [Auswählen]

% file […]cross-mint/bin/m68k-atari-mint-as
cross-mint/bin/m68k-atari-mint-as: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64]
cross-mint/bin/m68k-atari-mint-as (for architecture x86_64): Mach-O 64-bit executable x86_64
cross-mint/bin/m68k-atari-mint-as (for architecture arm64): Mach-O 64-bit executable arm64

d.h. das ist ein modernes Universal2-Binary mit x86_64 und arm64 Code-Zweigen.

Hatte erst ein paar Probleme. Obwohl da monterey läuft behauptet er steif und fest, das wäre ein x64-64 System. Was liefert bei dir

Code: [Auswählen]

$ uname -m
$ clang --print-target-triple


Code: [Auswählen]

% uname -m
arm64
goetz@Wintermute2 ~ % clang --print-target-triple
arm64-apple-darwin22.3.0

gcc muss ich noch schauen. Könnte etwas schwieriger werden, vor allem bei den zusätzlichen libraries (gmp, mpfr, und mpc). Sind die bei dir schon universal?

Die gibt’s alle drei (nativ für arm64) bei Homebrew, daher: ja.

[Thorsten Otto]

Ja, aber ich meinte ob das auch universal libraries sind (also x86_64 & arm64). Aber egal, das Problem sollte jetzt gelöst sein.

Gibt aber noch einige andere. Nach ca. 40 Versuchen mit hauptsächlich kleinen Änderungen läuft er relativ weit. Allerdings wird
a) das log-file abgeschnitten, weil zu lang (hatte zwischenzeitlich mal gesehen daß er schon bei Zeilennummern > 100000 war, was kein Wunder ist, wenn "sprintf" jetzt deprecated ist und er jedesmal 50 Zeilen produziert, um die ganzen Makros anzuzeigen...)
b) Nach über einer Stunde Laufzeit kam dann

Code: [Auswählen]

2023-02-06T17:03:04.2478080Z Undefined symbols for architecture x86_64:
2023-02-06T17:03:04.2480030Z   "_ZSTD_compress", referenced from:
2023-02-06T17:03:04.2506630Z       lto_end_compression(lto_compression_stream*) in libbackend.a(lto-compress.o)
2023-02-06T17:03:04.2572730Z   "_ZSTD_compressBound", referenced from:
2023-02-06T17:03:04.2607740Z       lto_end_compression(lto_compression_stream*) in libbackend.a(lto-compress.o)
...

beim linken von cc1. Da scheint wohl was zu fehlen in dem image für den runner, hoffentlich kann ich das umgehen. Aber wird's jetzt echt ätzend, wenn man jedesmal 'ne Stunde warten muss... Ganz abgesehen davon, daß das beim linken von cc1 war, dh. mit der c++-library hat er noch gar nicht angefangen. Und obs ein Zeit-Limit Für die jobs gibt weiss ich auch nicht.

[Thorsten Otto]

Komme der Sache näher. gcc 7.5.0 sollte theoretisch funktionieren jetzt (kann leider überhaupt keine tests machen, weil die executables für macosx >= 11 übersetzt werden müssen, und auch die x86_64 version auf High Sierra deswegen nicht läuft).

Siehe http://tho-otto.de/snapshots/crossmint/macos/

gcc 4.6.4 zickt noch ein bisschen rum, sollte aber auch bald folgen.

Was mich ein bisschen irritiert: meine mintelf toolchain funktioniert noch nicht. Wäre an sich nicht weiter tragisch, der Grund ist allerdings daß der ld beim configurieren der libcstdc++ mit segfault abschmiert. Ich hoffe daß da nicht noch ein Problem ist, evtl. liegt es aber auch nur am linker-plugin. Muss ich noch testen.

[Thorsten Otto]

Update: GCC 4.6.4 sollte jetzt auch gehen (zumindest lässt er sich kompilieren

[Thorsten Otto]

Schon getested? Es gab noch ein kleinen fix, aber theoretisch sollten jetzt alle Versionen funktionieren. Siehe auch https://www.atari-forum.com/viewtopic.php?t=42512

[goetz @ 3rz]

Schon getested? Es gab noch ein kleinen fix, aber theoretisch sollten jetzt alle Versionen funktionieren. Siehe auch https://www.atari-forum.com/viewtopic.php?t=42512

Aaah, da sind die. Ich hatte im Hauptverzeichnis über deine Homepage geschaut, nichts gefunden, wollte aber nicht quengeln.

<runterlad>

Die laufen alle erstmal sauber! Toll, danke! Ich habe jetzt nur HelloWorld.c übersetzt und nichts großes, aber es läuft durch, ist nativ, und schön. Wenn noch jemand ranmag: nach dem auspacken das Quarantäne-Flag entfernen mit sudo xattr -r -d com.apple.quarantine <programm>

[goetz @ 3rz]

Ah, halt, starten tun sie, beim bauen waren sie nicht im PATH, Sekunde … hm, nee, da läuft was gegen die Wand was ich nicht verstehe:

Für den 4.6.4:

Code: [Auswählen]

int main(void)
{
    return 1;
}


Code: [Auswählen]

~ % /Users/goetz/temp/opt/cross-mint/bin/m68k-atari-mint-gcc test.c -o test
clang: warning: argument unused during compilation: '-m68000' [-Wunused-command-line-argument]
/var/folders/lk/bcmg6yhn3r1_kplg35v7v_vr0000gp/T//cc46jGk9.s:3:2: error: unknown directive
        .even
        ^
/var/folders/lk/bcmg6yhn3r1_kplg35v7v_vr0000gp/T//cc46jGk9.s:6:9: error: unknown token in expression
        link.w %fp,#0 […]
/var/folders/lk/bcmg6yhn3r1_kplg35v7v_vr0000gp/T//ccO6Nkez.s:7:2: error: unrecognized instruction mnemonic, did you mean: asr, lsr, msr, sri, str?
        jsr ___main
        ^
/var/folders/lk/bcmg6yhn3r1_kplg35v7v_vr0000gp/T//ccO6Nkez.s:8:11: error: unknown token in expression
        moveq #1,%d0
                 ^
[…]

Für den 12er:

Code: [Auswählen]

% /Users/goetz/temp/opt12/cross-mint/bin/m68k-atari-mint-gcc-12.2.0  test.c -o test
clang: error: the clang compiler does not support '-mcpu=68000'

[Thorsten Otto]

Aaah, da sind die

Hatte eigentlich den link oben angegeben Auf der Hauptseite gibt es den aber auch jetzt.

hm, nee, da läuft was gegen die Wand was ich nicht verstehe:

Wenn du den compiler in ein anderes Verzeichnis installiert hast, hast du auch die binutils dort installiert? Wenn clang aufgerufen wird, ist das ein Zeichen daß er nicht den richtigen Assembler gefunden hat. In deinem Fall müsste das

Code: [Auswählen]

/Users/goetz/temp/opt/cross-mint/m68k-atari-mint/bin/as
sein. Dort ist dann wiederum ein symlink auf ../../bin/m68k-atari-mint-as zu finden.

Auch libraries wie mintlib, gemlib etc. solltest du dann dort installieren. Oder am besten gleich in /opt/cross-mint installieren

BTW gibt es bei macOS sowas wie update-alternatives, um festzulegen welches der default-compiler ist?

[Thorsten Otto]

[wollte aber nicht quengeln.
/quote]

Dafür quengel ich jetzt mal

Hast du es zum laufen bekommen? Ein wenig feedback wäre hilfreich...

[goetz @ 3rz]

Dafür quengel ich jetzt mal

Hast du es zum laufen bekommen? Ein wenig feedback wäre hilfreich...

-> PM