Hallo, ich habe ein Problem, beim Versuch etwas für mehrere Architekturen zu kompilieren das gegen die libglib2 gelinkt ist, bin ich auf die Nase gefallen weil es offensichtlich Probleme gibt wenn die Header Files (libglib2-dev) für mehrere Architekturen vorhanden sind, da die Definitionen dort inkompatibel sind (abgesehen davon was ich mir alles zumülle, wenn ich weitere Architekturen in den Paketmanager aufnehme und die entsprechende Lib immer einen riesen Rattenschwanz als Abhängigkeit einfordert, z.B. den nativen Compiler für diese Architektur der nie zum tragen kommen wird). Auch wenn es da eventuell irgendeinen Workaround gibt, bin ich am überlegen wie ich in Zukunft solche Probleme im vorhinein verhindern kann. Aus diesem Grund bin ich gerade am abwägen ob es sinnvoll ist für jede Architektur eine eigene chroot oder direkt ne komplette VM aufzusetzen, nur bin ich mir da nicht sicher welche Variante besser ist. Dabei bin ich auch auf die Frage gestoßen ob es beim Kompilieren für 32 Bit (x86) nicht besser wäre eine entsprechende VM auch direkt auf 32 Bit aufzusetzen und dann nativ zu kompilieren anstatt wieder von x64 auf x86 mittels cross-compiler zu arbeiten. Vorschläge? Bevor die Fragen nach der Umgebung kommt, es geht um Systeme unter Debian Buster/Bullseye und das Kompilieren mit gcc unter x64(x86-64) für x86(i686-linux-gnu, i686-w64-mingw32), x64(x86_64-linux-gnu, x86_64-w64-mingw32) und selten auch mal arm(arm-linux-gnueabi)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
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. So ganz klassisch mit ./configure --prefix /path/to/sysroot/of/toolchain Zum Bauen der Crosstoolchain dann noch http://crosstool-ng.github.io/ hernehmen. Ein, zwei Tage Einarbeitung braucht das aber bestimmt. Matthias
Μα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.
Tim T. schrieb: >> 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. 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. Matthias
Μα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.
:
Bearbeitet durch User
Ich fand diese Anleitung (auf Englisch) gut, hab sie aber selbst noch nicht umgesetzt: https://mcilloni.ovh/2021/02/09/cxx-cross-clang/
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. 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). 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. 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. Außerdem unterscheidet Conan Pakete nach Compiler-Version/Architektur/OS, sodass man hier nie versehentlich die falsche Variante einer Lib nutzen kann. Conan ist auch mit allen möglichen Buildsystemen kompatibel.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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 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... 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. 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. Ähnlich einfach & komfortabel wie es in anderen Sprachen selbstverständlich ist, z.B. bei Java mit Gradle. 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. Ein Projekt ohne Tickets ist tot ;-) Ein Vorteil den ich vergessen hab: Conan kann auch dynamisch vs. statische Bibliotheken unterscheiden, sodass man problemlos auf Wunsch seine Bibliotheken extern einbinden kann (z.B. indem man sich automatisch die .dll / .so / .dylib -Dateien von conan selbst zusammenstellen lässt) oder eben statisch in die eigene Anwendung einbinden kann. Das kann auch selektiv sein, sodass man z.B. libs wie Glfw statisch in die ausführbare Datei einbindet, aber z.B. die X-Core-Libs und die libc dynamisch linkt. Dadurch erhält man eine maximal kompatible "self-contained" Programmdatei. Das geht natürlich auch ohne conan, aber conan macht es einfach zwischen den Varianten flexibel umzuschalten durch die "shared" Option, welche man in der conanfile angibt.
:
Bearbeitet durch User
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...
:
Bearbeitet durch User
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.
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...
Tim T. schrieb: > glib - nix https://conan.io/center/glib Tim T. schrieb: > libusb https://conan.io/center/libusb Tim T. schrieb: > libssl https://conan.io/center/openssl Tim T. schrieb: > libntfs - nix > slang2 - nix Gibt's tatsächlich nicht.
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. ;-)
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. 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.
:
Bearbeitet durch User
Im Anhang mal ein minimales Testprojekt in C welches Glib, libusb und OpenSSL nutzt und für Linux x86 kompiliert, unter einem aktuellen Ubuntu. Erst C-Library für x86 installieren:
1 | sudo apt-get install gcc-multilib g++-multilib |
Dann die Conan-Pakete installieren:
1 | conan install -s arch=x86 --build=missing . |
Makefiles generieren:
1 | cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Release . |
Und kompilieren:
1 | make |
Die CMakeLists.txt könnte man noch besser mit Toolchain files machen anstatt x86 hart zu kodieren, das ist als Übung überlassen sofern CMake überhaupt gewünscht ist :)
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.
Tim T. schrieb: > Hatte das so verstanden, dass zumindest die Beschreibung für die > entsprechende Architektur vorhanden sein muss Die Beschreibung, d.h. das Recipe (in Form einer conanfile.py) ist plattformunabhängig. Damit kann man beliebig nativ oder cross kompilieren, sofern es eben nicht verbuggt ist :-) Daraus werden dann Binärpakete für die jeweiligen Architekturen gebaut, und das Conan-Projekt macht das mangels Rechenleistung nicht für x86. Das kann man aber eben auch selbst machen, conan macht es automatisch. Hier z.B. das Recipe für GLib: https://github.com/conan-io/conan-center-index/blob/master/recipes/glib/all/conanfile.py
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.