Forum: Compiler & IDEs Cross compiling vs nativ und VM vs chroot


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Tim T. (tim_taylor) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Daniel B. (dbuergin)


Bewertung
0 lesenswert
nicht lesenswert
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
von Tim T. (tim_taylor) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Μαtthias W. (matthias) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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

von Tim T. (tim_taylor) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Μα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.

von Μαtthias W. (matthias) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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

von Tim T. (tim_taylor) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Μα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
von W. (Gast)


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

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

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Tim T. (tim_taylor) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Tim T. (tim_taylor) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Tim T. (tim_taylor) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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...

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert

von Tim T. (tim_taylor) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Niklas G. (erlkoenig) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

von Tim T. (tim_taylor) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.