Moin, ich möchte eine Cross-Compiling-Umgebung für den bananapi-Pro aufsetzen. Das Host-System ist Ubuntu 14, auf dem BPro läuft ebenfalls Ubuntu 14 (LUbuntu). Hat jemand Tips/Ratschläge/Erfahrungen dazu/damit? Ich bin gerade dabei, mich in Scratchbox einzuarbeiten, das klingt recht vielversprechend. Hat das schon mal jemand benutzt? Es geht nicht (nur) um den Kernel sondern hauptsächlich um Anwendungen, die üblicherweise einen Haufen ARM-compilierter Libraries dazulinken, und ich will natürlich nicht das ganze System parallel noch einmal auf dem Host pflegen müssen. Comments are welcome. Danke
Vancouver schrieb: > und ich will natürlich nicht das ganze System parallel noch einmal auf > dem Host pflegen müssen. du musst eh 2 Versionen pflegen. Einmal die ARM und einmal die x68.
> du musst eh 2 Versionen pflegen. Einmal die ARM und einmal die x68. Ich meinte, ich will keine Kopie des ARM-Systems auf dem PC hosten, nur um das Cross-Compiling machen zu können. Die beiden ARM-Systeme müsste ich nämlich konsistent halten. Deswegen meine Idee mit der Scratchbox.
Vancouver schrieb: > Es geht nicht (nur) um den Kernel sondern hauptsächlich um Anwendungen, > die üblicherweise einen Haufen ARM-compilierter Libraries dazulinken, > und ich will natürlich nicht das ganze System parallel noch einmal auf > dem Host pflegen müssen. Wenn dein Cross-Compiler auch linken soll, dann müssen die Libraries dort verfügbar sein. Die Header sowieso. Option, wenn es dir nicht so sehr ums Cross-Compilen an sich, als eher um schnelleres Compilieren geht: distcc. auf dem BPi läuft dann je nach Config nur noch make und Präprozessor&Linker, das Compilieren kannst du auf einen ganzen Server-Park verteilen. Die "Arbeitssklaven" brauchen dazu nur den nackten (arm-) Compiler, keine Header oder Libraries.
> Option, wenn es dir nicht so sehr ums Cross-Compilen an sich, als eher > um schnelleres Compilieren geht: distcc. Ja, darum geht es eigentlich. Kleinere Programme habe ich immer direkt auf dem BPi übersetzt, aber das Paket, das ich jetzt übersetzen will (GnuRadio), braucht in der x86-Version eine gute Stunde (mit 6 Cores). Das brauche ich auf dem BPi gar nicht zu probieren. DistCC hatte ich noch garnicht auf dem Schirm... vielen Dank für den Tip.
Ich habe noch ein Mini-System mit einem Arm von TI. Für diesen haben ich auf dem Linux-PC die Linaro-Toolchain installiert: https://www.linaro.org/downloads/ Damit kann ich auch einem Intel Linux die Arm Programme kompilieren. Es sind Gcc, Linker und einige Tools mit dabei. Auch die Basisbibliotheken sind integriert. Müßte man mal ausprobieren, ob das auch für den Raspi passt.
Vancouver schrieb: > aber das Paket, das ich jetzt übersetzen will > (GnuRadio), braucht in der x86-Version eine gute Stunde (mit 6 Cores). sicher das dein System sonst ok ist? Der Linux kernel braucht nicht mal nur 20min mit einen Kern auf meinem System. Ist GnuRadio wirklich "groß"?
> sicher das dein System sonst ok ist? Der Linux kernel braucht nicht mal > nur 20min mit einen Kern auf meinem System. Hat mich auch gewundert. Keine Ahnung, warum GnuRadio so ein Act ist. Auf einem Dualcore-Notebook läuft das knappe 5 Stunden, aber ich glaube da ist das Problem der knappe Speicher (swapping). Der "normale" Linux-Kernel braucht bei mir etwa 5 Minuten mit 6 Kernen, das passt ungefähr.
@PittyJ:
> Auch die Basisbibliotheken sind integriert.
Wenn es um den Kernel geht, reicht das vermutlich. Aber für Anwendungen
braucht man noch alle möglichen weiteren Libraries (fftw, usb, png, weiß
der Kuckuck was...)
Vancouver schrieb: > @PittyJ: > >> Auch die Basisbibliotheken sind integriert. > > Wenn es um den Kernel geht, reicht das vermutlich. Aber für Anwendungen > braucht man noch alle möglichen weiteren Libraries (fftw, usb, png, weiß > der Kuckuck was...) Da hast du aber was vor ...
1 | [ebuild N ] net-wireless/gnuradio-3.7.8:0/3.7.8::gentoo to /usr/armv7a-hardfloat-linux-gnueabi/ USE="alsa analog audio digital filter qt4 utils -atsc -channels -doc -dtv -examples -fcd -fec -grc -jack -log -noaa -oss -pager -performance-counters -portaudio -sdl {-test} -trellis -uhd -vocoder -wavelet -wxwidgets -zeromq" PYTHON_TARGETS="python2_7" |
nehme ich mal QT weg dann sind es ca.
1 | USE="-qt4" emerge-armv7a-hardfloat-linux-gnueabi -p gnuradio | wc -l |
2 | |
3 | The following USE changes are necessary to proceed: |
4 | (see "package.use" in the portage(5) man page for more details) |
5 | # required by sci-libs/scipy-0.16.0::gentoo
|
6 | # required by net-wireless/gnuradio-3.7.8::gentoo[filter]
|
7 | # required by gnuradio (argument)
|
8 | >=dev-python/numpy-1.9.2 lapack |
9 | 75
|
weil da dev-python/numpy unmasked werden muss. Schaue mal auf https://wiki.debian.org/ArmHardFloatPort da hast du weniger Arbeit (für einen Anfänger) in Cross Compiling
> Da hast du aber was vor ... Ja, ich weiß, das ist ein dicker Brocken. Aber ich brauche nicht alles davon, der BPi soll sozusagen als GnuRadio-Server arbeiten, also nur die Signalverarbeitung machen. Damit fällt das ganze QT-Zeug weg, weil es keine GUI gibt, und den Audio-Kram brauche ich auch nur zum Teil. Evtl kann ich auch auf Teile der Python-Module verzichten, da bin ich noch nicht ganz durchgestiegen. > Schaue mal auf > https://wiki.debian.org/ArmHardFloatPort Super Tip, danke! Das schaue ich mir mal an. Ich sehe schon, das war eine sehr gute Idee hier zu posten.
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.