Cross compiling vs nativ und VM vs chroot

Daniel B. schrieb:
> Die ganze Docker Geschichte hast Du Dir angeschaut? Bin mich auch erst
> am einarbeiten, könnte aber einen Möglichkeit sein.
> z.B.
> https://ownyourbits.com/2017/06/20/c-build-environment-in-a-docker-container/
>
> Also pro Umgebung ein Docker Image mit allem drin.

Ja, es ist schwer den Docker Hype der letzten Jahre nicht mitbekommen zu 
haben, bietet in diesem Fall allerdings (praktisch) keinen Vorteil 
gegenüber chroot, da in meinem Fall keine Vorteile von getrennten 
Namespaces genutzt werden oder irgendwelche Sicherheitskritische 
Bedenken herrschen.
Gegenüber der VM bieten Docker Container natürlich den Vorteil das der 
Kernel nicht mit virtualisiert werden muss, allerdings war die VM Idee 
auch eher in Kombination mit einem 32 Bit System in der VM und nativem 
kompilieren in 32 Bit auf diesem gedacht.

Μαtthias W. schrieb:
> Hi
>
> Du könntest doch einfach für deine Targets Crosstoolchains bauen (mit
> sysroot) und da rein dann die von dir benötigten Bibliotheken bauen.

Also aus der Toolchain ein ganzes SDK machen...puh.

> So ganz klassisch mit ./configure --prefix /path/to/sysroot/of/toolchain

Die Variante hatte ich im Übrigen auch schon probiert, nur hatte ich da 
dann Probleme weil manche Tools, z.B. der Midnight Commander beim Bauen 
den Prefix hart in die Binary übernehmen und Probleme haben wenn die 
libs dann woanders (/lib, /usr/lib) liegen wenn es auf dem Zielsystem 
läuft. Der Trick war dann den Prefix auf / oder /usr zu setzen und mit 
"Make DESTDIR=/path/to/sysroot install" das Ding an seinen 
Bestimmungsort zu verfrachten.

> Zum Bauen der Crosstoolchain dann noch http://crosstool-ng.github.io/
> hernehmen. Ein, zwei Tage Einarbeitung braucht das aber bestimmt.

Jup, das crosstool-NG ist prinzipiell bekannt, nur wollte ich mir 
eigentlich das Leben einfacher machen und nicht alle Libs nochmal selber 
bauen müssen. Stell dir nur mal den xorg-server vor... Aber wenn keine 
anderen guten Vorschläge kommen werde ich das wohl angehen müssen.

Μαtthias W. schrieb:

> Ist lästig bis das mal läuft aber wenns läuft hast du dein System halt
> auch komplett selber im Griff. Ich bereue es nicht den Weg gegangen zu
> sein. Eine kleine Abkürzung könnte buildroot sein. Wobei ich das dafür
> noch nie verwendet habe.

Genau das ist der Grund warum ich von Buildroot weg will, es ist einfach 
eine weitere Ebene Komplexität die ich gerne vermeiden möchte. Im 
aktuell konkreten Fall geht es um eine Portierung von einem minimalen 
Linuxsystem was ich irgendwann mal für den Raspberry mit Buildroot 
angefangen habe und später als Rettungssystem für x64_86 direkt auf 
x64_86 ausgebaut habe, dann kamen ältere Atom Thinclients dazu die nur 
x86 konnten und jetzt will ich alles aus einem Guss machen.

Aber danke schonmal für den Input.

Ich fand diese Anleitung (auf Englisch) gut, hab sie aber selbst noch 
nicht umgesetzt:

https://mcilloni.ovh/2021/02/09/cxx-cross-clang/

Niklas G. schrieb:
> conan.io ist ein Paketmanager welcher Bibliotheken für verschiedene
> Plattformen ausliefern kann. Den Compiler muss man selbst installieren,
> aber damit kann man gut reproduzierbare Ergebnisse auch beim
> Cross-Compilieren erreichen bei hoher Flexibilität (Optionen für
> Abhängigkeiten definierbar). Ist auch super für CI geeignet.

Auf den ersten Blick hätte ich es als weiteren Hipster Blödsinn abgetan, 
diese Art Webseiten erzeugt bei mir irgendwie Abneigung, auch wenn es in 
diesem Fall durchaus interessant sein könnte. Sieht oberflächlich 
einfach wieder nach Zeug für die "Maker"-/IoT-Jünger aus wo 
systematisches Vorgehen und Erfahrung durch intelligente Software 
ersetzt werden soll.

> Das Projekt ist noch relativ jung und gerade bei exotischeren
> Kombinationen (z.B. Linux->Mac OS X crosscompiling) gibt es noch diverse
> Bugs in den Paketdefinitionen, für die man aber recht gut Fixes
> einreichen kann (pull-requests).

Ok, solange es besser wird und nicht Features vor Fixes setzt, ist es ja 
gut.

> Man kann auch eigene Pakete definieren und über einen eigenen Server
> ausliefern. Die GitLab Enterprise Version hat einen Server dafür
> integriert, für falls die Firma das sowieso schon nutzt.

Nett, nur für meine Belange reicht bislang ein normales Git bzw. Github, 
also nicht ganz die Zielgruppe.

> Am Besten ist m.M.n an conan das Options-Konzept - Pakete bieten
> Optionen an, welche man in seiner eigenen Anwendung entsprechend setzen
> kann (z.B. um nicht benötigte Features abzuschalten), und conan lädt
> dann das entsprechend vorkompilierte Binärpaket herunter falls
> vorhanden, oder kompiliert es eben selbst. Dadurch vermeidet man das
> klassische Problem, dass "normal" auf dem OS installierten Bibliotheken
> nicht ohne weiteres anzusehen ist, welche Optionen/Features dort
> aktiviert sind, und man Konflikte bekommt wenn man einen bestimmten Satz
> an Optionen braucht der sich nicht mit der installierten Version deckt.
> Die Optionen werden in einem Hash codiert, nach welchem das lokale
> Installationsverzeichnis der libs benannt wird.

DAS ist wirklich interessant und auch der Grund warum ich es mir bei 
Gelegenheit anschauen werde, wenn es dann etwas abgehangen ist. Aktuell 
sind mir die 1,5k Tickets etwas viel.

> Außerdem unterscheidet Conan Pakete nach
> Compiler-Version/Architektur/OS, sodass man hier nie versehentlich die
> falsche Variante einer Lib nutzen kann.

Bis auf das oben angesprochene Options Problem nicht wirklich ein akutes 
Problem, aber auch nett.

> Conan ist auch mit allen möglichen Buildsystemen kompatibel.

Ebenfalls für diejenigen die es brauchen ein Gewinn.

Also insgesamt sieht es durchaus interessant aus und wird später mal 
angeschaut, aktuell wird es aber wohl erstmal etwas schlichteres werden.

Niklas G. schrieb:
> Tim T. schrieb:
>> Sieht oberflächlich
>> einfach wieder nach Zeug für die "Maker"-/IoT-Jünger aus wo
>> systematisches Vorgehen und Erfahrung durch intelligente Software
>> ersetzt werden soll.
>
> Eine Software nach ihrem Webdesign zu beurteilen ist aber auch
> oberflächlich... Das Rumbasteln mit Buildsystemen und

Natürlich, aber das ist bei mir nunmal der erste Eindruck und ich habe 
weder die Zeit noch die Lust mich mit jeder Sau zu beschäftigen die 
irgendwann mal durchs Dorf getrieben wird. Nenne es oberflächlich, dumm 
oder ignorant, aber nach irgendeinem Kriterium muss man nunmal filtern.

> Binär-Inkompatibilitäten ist eine ziemlich ätzende Angelegenheit, die
> kann man gern automatisieren. Die Nutzer praktisch aller anderen
> Sprachen würden sich gruseln wenn sie wüssten, womit sich C++ &
> C-Programmierer rumschlagen müssen...

Auch das ist wahr, in Bereichen wo es geht setze ich auch immer lieber 
C# oder ähnliches ein, aber manchmal muss es eben C sein. Wobei ich 
zugeben muss, dass dieses knietief im Morast stehen auch eine gute 
Schule sein kann; wenn man es dann aber gelernt hat, mit den 
Alternativen produktiver sein kann.

> Tim T. schrieb:
>> Bis auf das oben angesprochene Options Problem nicht wirklich ein akutes
>> Problem, aber auch nett.
>
> Wenn man mehrere Zielplattformen hat, ist die Verwaltung der einzelnen
> Bibliotheken schon ziemlich lästig.

Ist lästig aber durch entsprechende Arbeitsweise beherrschbar; ist wie 
die Garbage Collection, es geht auch ohne wenn man systematisch arbeitet 
und empfindet die dann auch nicht als fehlend.

> Tim T. schrieb:
>> aktuell wird es aber wohl erstmal etwas schlichteres werden.
>
> Auch für einfache Projekte ist es super - eine kleine "conanfile.txt"
> ins Projekt anlegen, in ein paar Zeilen definieren welche Abhängigkeiten
> man hat, im Buildsystem conan einbinden (z.B. bei CMake: ein paar Zeilen
> Copy&Pasten), "conan install" aufrufen, fertig.
>
> Tim T. schrieb:
>> Aktuell
>> sind mir die 1,5k Tickets etwas viel.
>
> Je mehr Tickets, desto aktiver das Projekt. Meine Tickets wurden meist
> zügig behoben, sofern ein guter fix vorgeschlagen wurde.

Das ist mit Sicherheit auch in gewissem Maße Ansichtssache.
Es wird eh schon einiges an Arbeit die ganzen Libs zu bauen und mich mit 
den Problemen dabei herumzuschlagen. Wenn ich mich dann auch noch in 
einen neuen Paketmanager mit seinen Eigenheiten einarbeiten muss, geht 
meine Toleranzschwelle bei nicht selbst verschuldeten Problemen in den 
Werkzeugen schnell gegen Null...

Niklas G. schrieb:
> Tim T. schrieb:
>> Es wird eh schon einiges an Arbeit die ganzen Libs zu bauen und mich mit
>> den Problemen dabei herumzuschlagen.
>
> Der Witz an conan ist, dass du genau das nicht machen musst. Das geht
> automatisch, sofern schon jemand ein Paket dafür definiert hat. Im
> Idealfall besteht der Arbeitsaufwand für das Einbinden einer Bibliothek
> aus dem Schreiben einer einzigen Zeile in der conanfile.txt.

Tja, hab gerade mal über die Suche auf conan.io die ersten 5 Libs 
gesucht die mir spontan eingefallen sind für Linux und x86:

glib - nix
libusb - nix
libssl - nix
libntfs - nix
slang2 - nix

Also in meinem Fall aktuell noch keine Erleichterung. Aber mir ist schon 
klar welche Stärke (bei manchen Sachen auch ein gewisses Risiko) da drin 
liegt und wenn es von einer größeren Anzahl an Leuten genutzt wird zum 
Selbstläufer werden kann; nur für mich aktuell eben nicht. Wobei es 
natürlich ein Henne/Ei- Problem ist, würde ich es nutzen wären innerhalb 
kürzester Zeit die oben genannten Libs im Index...

Niklas G. schrieb:

> https://conan.io/center/glib
> https://conan.io/center/libusb
> https://conan.io/center/openssl

Aber nicht als x86, nur x86_64. ;-)

Niklas G. schrieb:
> Tim T. schrieb:
>> Aber nicht als x86, nur x86_64. ;-)
>
> Die x86-Version würde dann automatisch kompiliert wenn du das erste Mal
> "conan install" aufrufst. Da geduldet man sich 10 Minuten und dann ist
> es erledigt. Du kannst die x86-Version auch auf einen eigenen Server
> hochladen, wenn du oft von verschiedenen PC's aus kompilierst und nicht
> auf jedem PC einzeln PC die 10 Minuten warten kannst.

Ok, jetzt hast du mich neugierig gemacht, falls das wirklich 
funktioniert.
Kann mir noch nicht ganz vorstellen wie er alle Abhängigkeiten und 
Eigenheiten berücksichtigen will, aber ich werde es mal testen.

> Das Conan-Projekt hostet nur Binär-Pakete für populäre Targets, aber der
> Witz an der Sache ist ja, dass conan selbsttätig nach Bedarf das Paket
> für die Wunsch-Plattform kompiliert und einrichtet.

Hatte das so verstanden, dass zumindest die Beschreibung für die 
entsprechende Architektur vorhanden sein muss und die Kompilierung dann 
erfolgt wenn man das entsprechende Paket auf eben dieser Architektur, 
nur mit anderen Optionen haben will. Das er von einer x86_64 
Beschreibung bei Bedarf zuverlässig ein x86 Objekt baut, wäre natürlich 
die Eierlegende Wollmilchsau.