Große Projekte auf Android - linker out of memory

[jaenicke]

Hallo,

nachdem der Linker bei Delphi 10 Seattle schon bei unseren Packages mit gemeinsamen Units ausgestiegen war, lassen sich diese nun unter 10.1 Berlin kompilieren und linken.
Das ist schon einmal ein Fortschritt, auch wenn das größte Projekt irgendwann einen internen Fehler meldet und erst im zweiten Anlauf fertig kompiliert.

Daraufhin haben wir unsere Hauptanwendung ebenfalls kompilierbar bekommen nach kleineren Änderungen. Das Problem ist aber dass der Linker immer mit Out-Of-Memory aussteigt.

Ich frage mich nun, ob überhaupt schon jemand größere Apps mit Delphi erstellt hat.

Zum Vergleich:
Die gemeinsamen Units dürften zusammen rund 2 Millionen Zeilen Quelltext haben, die App selbst, die darauf zurückgreift, ca. 300.000 Zeilen.
Die kompilierten gemeinsamen Units sind etwa 1,3 GiB groß, die der Anwendung noch einmal über 300 MiB.

Hat jemand schon Apps in dieser Größenordnung erstellt?

Ansonsten bliebe als Alternative eine abgespeckte Mini-Version als App zu erstellen. Schön wäre das aber nicht.

Vielen Dank und schönen Gruß,
Sebastian Jänicke

[Bambini]

Zitat:

Zitat von jaenicke (Beitrag 1339806)

Zum Vergleich:
Die gemeinsamen Units dürften zusammen rund 2 Millionen Zeilen Quelltext haben, die App selbst, die darauf zurückgreift, ca. 300.000 Zeilen.
Die kompilierten gemeinsamen Units sind etwa 1,3 GiB groß, die der Anwendung noch einmal über 300 MiB.

Verstehe ich das richtig, deine Windows EXE ist 300MB groß?

Zitat:

Zitat von jaenicke (Beitrag 1339806)

Hat jemand schon Apps in dieser Größenordnung erstellt?

Denke das 300MB Apps auf mobilen Geräte keine gute Idee ist.

[bra]

Versuch mal ob es funktioniert, wenn du in den Projekteinstellungen den externen Build aktivierst. Vor Seattle war das die Lösung, falls die Projekte nicht erstellt werden konnten.
Wobei 300 MB für die Anwendung (exe?) schon echt happig ist. Habt ihr die ganzen Ressourcen da mit drin?

[jaenicke]

Nein, die Exe unter Windows ist als Release Build 29 MiB groß.

Ich meine mit der Größe auch nicht das fertige Kompilat, sondern die .dcu und .o Dateien. Einen anderen Größenvergleich habe ich ja leider nicht solange der Linker nicht durchläuft.

Die kompilierten gemeinsamen Units für Win32 sind nicht einmal ein Zehntel so groß, nämlich 90 MiB. Und die der Anwendung selbst noch einmal knapp 40 MiB.
Das heißt derselbe Quelltext (für Win32 sogar noch etwas mehr, weil IFDEFs Teile davon für Android ausschließen), resultiert für Android in zusammengenommen 1,6 GiB kompilierter Units während es für Win32 lediglich 130 MiB sind...

Angesichts dieser Zahlen verstehe ich durchaus das OutOfMemory des Linkers, aber ich frage mich, ob das normal ist und es schlicht niemand so benutzt oder ob da etwas schief läuft.

[Uwe Raabe]

Ich bin mir nicht sicher, ob wir hier über denselben Sachverhalt reden, aber ich hatte auch mal ein Projekt, das beim Compilieren ein Out-Of-Memory in der Android-ToolChain erzeugte. Leider weiß ich nicht mehr, wo genau.

Abhilfe schaffte die Verwendung des NDK 10 statt 9, da die dortigen Tools mitlerweile als 64-Bit Applikationen vorliegen.

[jaenicke]

Danke, mit dem NDK 11 läuft das Linken in der Tat durch... sogar im Debugmodus.
Die .so ist als Debugversion 275 MiB groß... (zum Vergleich, die Windowsversion hat 100 MiB als Debugversion).

Dann werde ich mal den Buildprozess entsprechend einrichten... mal schauen...

Vielen Dank auf jeden Fall. Dass es daran liegen könnte, daran habe ich nicht gedacht.

[mensch72]

wie stellt man das NDK von 9 auf 11 um ?

[jaenicke]

Hier gibt es die Version, ich habe die für Windows 64-Bit benutzt:
https://developer.android.com/ndk/do...dex.html?hl=ko

Ich habe sie an die gleiche Stelle gepackt wie Delphi selber:
C:\Users\Public\Documents\Embarcadero\Studio\18.0\ PlatformSDKs\android-ndk-r11c

Und dann in Delphi unter "Tools --> Optionen --> Umgebungsoptionen --> SDK Manager" das Verzeichnis eintragen, sprich aus android-ndk-r9c machst du android-ndk-r11c.
Und bei Punkt 3 sieht das bei mir dann so aus (Punkt 4 analog):
C:\Users\Public\Documents\Embarcadero\Studio\18.0\ PlatformSDKs\android-ndk-r11c\toolchains\arm-linux-androideabi-4.9\prebuilt\windows-x86_64\bin\arm-linux-androideabi-strip.exe
Sprich statt windows nun windows-x86_64 (weil ich die 64-Bit Variante genommen habe).

[TurboMagic]

In dem man das neuere NDK aus dem Internet herunterlädt, in einen leeren ordner entpackt und in Delphi unter Tools/Optionen in den SDK Einstellungen die Pfade zum NDK anpasst.

[jaenicke]

Jetzt klappt das mit dem Kompilieren, auch installieren und starten lässt sich die App im Debugger. Ich bekomme aber nun immer einen Segmentation Fault an Adresse 0 bevor ich an eine Stelle komme, an der ich debuggen könnte. Die App kommt noch nicht einmal bis zum initialization der System.SysUtils, die in der uses des Projekts innerhalb der System.StartUpCopy.pas weit oben steht.

Hat jemand irgendeine Idee wie ich so etwas debuggen kann? Am besten ohne die App langsam auseinander zu nehmen bis es geht, was aktuell meine einzige Idee wäre.

[mensch72]

bei seltsamen "Startfehlern" nutze ich als "DebugView" ein verbundenes Androidstudio und schaue mir da komplett oder gefiltert alle OS-Messages an. Da sieht man mehr wie in der RS-IDE

(den letzten "Start Segmentation Error" hatte ich z.B., weil ein Projekt mit NFC-Komponente von WinSoft eine benötigte "Lib" nicht (mehr) mit eingebunden hatte, als wir es von 10.0u1 auf aktuellem Berlin10.1 übersetzt haben...)

[Rollo62]

Segmentation fault habe ich auch schonmal durch einfaches Aufräumen und Umstellen der uses Einträge wegbekommen. Anscheinend kann es Linkergrenzen überschreiten wenn 16GB Sprünge überschritten werden.
Die Reihenfolge scheint wichtig zu sein damit der Linker das richtig zusammenbekommt.

Rollo

[bra]

Zitat:

Zitat von Rollo62 (Beitrag 1342270)

Segmentation fault habe ich auch schonmal durch einfaches Aufräumen und Umstellen der uses Einträge wegbekommen. Anscheinend kann es Linkergrenzen überschreiten wenn 16GB Sprünge überschritten werden.
Die Reihenfolge scheint wichtig zu sein damit der Linker das richtig zusammenbekommt.

Das kann ich bestätigen. Wenn ich bei uns im DPR die Reihenfolge der uses ändere, bekomme ich auch regelmäßig irgendwelche Linker-Fehler.

[jaenicke]

Ohje... das würde erklären warum abgespeckte Versionen funktionieren... aber auch nicht immer...
Das kann ja heiter werden. Ich teste noch...

[nikosophi]

Just for Info:
Ich weiss, der Beitrag ist schon älter, aber nach dem Berlin Update 2 war bei mir jedenfalls das NDK 9 noch installiert.

jetzt (Berlin 10.1 Update 2) gehört es ins Unterverzeichnis von Verzeichnis:

c:\Users\Public\Documents\Embarcadero\Studio\18.0\ CatalogRepository\

und ist in Version 13:
https://developer.android.com/ndk/do...dex.html?hl=ko

32 Bit:
android-ndk-r13b-windows-x86.zip

64 Bit:
android-ndk-r13b-windows-x86_64.zip

[Uwe Raabe]

Zitat:

Zitat von nikosophi (Beitrag 1360841)

jetzt (Berlin 10.1 Update 2) gehört es ins Unterverzeichnis von Verzeichnis:

c:\Users\Public\Documents\Embarcadero\Studio\18.0\ CatalogRepository\

Eigentlich ist es egal wo das SDK/NDK liegt, solange du die Pfade in die Konfiguration einträgst. Das spart insbesondere bei mehreren Delphi-Versionen eine Menge Platz.