ARM Cross Compiling unter Mac OS X

(English version)

Vor einiger Zeit hatte ich schon einmal in Artikel das cross compiling unter Mac OS X für den Raspberry Pi mit Eclipse beschrieben. Wozu nun also noch einmal über das gleiche Thema schreiben? Nun ganz einfach, es geht noch viel mehr als nur Standard C/C++ und es gibt auch noch andere Targets. Des weiteren ist es mir gelungen, die Linaro ARM Toolchains, sowohl für den Raspberry Pi als auch für den BeagleBone Black, auf dem Mac zu kompilieren.

Der Artikel bezieht sich zwar hauptsächlich auf das Cross Kompilieren unter Mac OS X, alle was im folgenden beschrieben wird kann aber auch eins zu eins auf linux angewendet werden.

ARM Toolchain für Mac OS X

Beginnen wir also zunächst mit Toolchain. Damit nicht jeder die Toolchain erneut kompilieren muss, habe ich sie als Binary bereitgestellt:

Die beiden Versionen sollten auch für die jeweiligen Derivaten eingesetzt werden können.

Alle Versionen liegen im Package Manager Format, also als Installationsroutine, vor. Nach der Installation befinden sich die Toolchains in den folgenden Verzeichnissen:

  • /usr/local/linaro/arm-linux-gnueabihf  – BeagleBone Black
  • /usr/local/linaro/arm-linux-gnueabihf-raspbian  – Raspberry Pi

Nun kann man eigentlich schon mit dem cross kompilieren beginnen:

Den populärsten Cod eingeben:

Die Datei speichern, nano Verlassen [ctrl+x] und danach kompilieren:

Nun noch testen ob alles funktioniert hat:

Hat das alles so funktioniert könnte man gleich zu Eclipse übergehen. Aber zur Zeit verfügen wir lediglich über eine „prebuild sysroot“. Das bedeutet, wir können nur Code mit  Standard C und Standard C++ erzeugen. Soll auf bereits vorhandene Linux Bibliotheken, wir Glib etc., zurückgegriffen werden, müssen diese erst kompiliert werden.

Erweiterte Sysroot

Es existieren ein Unzahl an Linux Bibliotheken, die ich natürlich hier nicht alle verwendet werden. Ich beschränke mich auf die gängigen bzw. auf diese die ich als gängig bezeichne. Ich erläutere hier nicht die Konfiguration sprich:

Sonder das Ganze ist in ein Bash Script verpackt, welches die erweitert Sysroot automatisch erstellt. Ursprünglich wollte ich nur die Bibliotheken Glib, Qt und OpenCV haben, jedoch besitzen diese wiederum weitere Abhängigkeit, so dass die Sysroot nun über die Folgenden Bibliotheken verfügt:

  • Image Libraries:
    • libjpeg – Independent JPEG Group’s JPEG runtime library
    • limping – PNG library
    • libtiff – Tag Image File Format library
    • libraw – raw image decoder library
    • liblcms2 – Little CMS 2 color management library development headers
    • imagemagick – image manipulation library
  • Audio and Video Libraries:
    • gstreamer – pipeline-based multimedia framework
    • gst-plugins-base – GStreamer libraries from the „base“ set
    • gst-plugins-good – GStreamer development files for libraries from the „good“ set
    • alsa – Advanced Linux Sound Architecture
    • liboog – Ogg bitstream library
    • libvorbis – Vorbis General Audio Compression Codec
    • libtheora – Theora Video Compression Codec
    • libvisual – Audio visualization framework
    • wavpack – Audio codec (lossy and lossless) encoder and decoder
    • taglib – Library for reading and editing the meta-data of audio formats 1.
  • Compression Libraries:
    • zlib – Compressing File-I/O Library
    • bzip2 – High-quality block-sorting file compressor
    • liblzma – XZ-format compression library
  • Markup Language Libraries:
    • expat – XML parsing C library
    • libxml2 – GNOME XML library
  • Hardware Libraries:
    • tslib – Abstraction layer for touchscreen
    • i2c-tools – Heterogeneous set of I2C tools for Linux
    • bluez – Bluetooth protocol stack library
  • Communication:
    • libmodbus – Library for the Modbus protocol
    • curl – Command line tool for transferring data with URL syntax
  • Mathematic and Scientific Libraries:
    • gsl – GNU Scientific Library
    • gmp – Multi precision arithmetic library developers tools
    • mpfr – Multiple precision floating-point computation developers tools
    • opencv – Open Source Computer Vision Library
  • Database:
    • sqlite – Database management system libraries
  • Assistance Libraries:
    • Qt – Qt 4 development files and development programs for host 1.
    • glib – GLib development library
    • dbus – Simple interprocess messaging system
    • libffi – Foreign function interface library
    • ncurses – text-based user interfaces library
    • readline – GNU readline and history libraries
    • cryptodev – Access to Linux kernel cryptographic drivers
    • openssl – Secure Sockets Layer toolkit
    • liborc – Library of Optimized Inner Loops Runtime Compiler
    • freetype – FreeType 2 font engine
    • fontconfig – Generic font configuration library
    • cairo – The Cairo 2D vector graphics library
    • liblqr – Converts plain array images into multi-size representation
    • libssh2 – SSH2 client-side library
  • X11 Libraries:
    • libX11 – X11 client-side library
    • libXext – X11 miscellaneous extensions library
    • pixman – pixel-manipulation library for X
    • xtrans – X transport library
    • xproto
    • xextproto
    • inputproto
    • xcb-proto – X C Binding
    • libpthread-stubs – pthread stubs not provided by native libc
    • libXau – X11 authorisation library
    • libgpg-error – Library for common error values and messages in GnuPG components
    • libgcrypt – LGPL Crypto library
    • libxslt – XSLT 1.0 processing library
    • libxcb – X C Binding
    • videoproto – X11 Video extension wire protocol
    • kbproto – X11 XKB extension wire protocol
    • libXv – X11 Video extension library

Zunächst muss das Script von Github geladen werden. Ich verwende hierfür einen Ordner Namens „Development“ der in meiner Benutzerverzeichnis liegt, in dem wiederum Unterordner der einzelnen Targets vorhanden sind. Da sich dies innerhalb des Artikels fortführt hier die Kurze Erläuterung:

  • Das Benutzerverzeichnis /Users/USER_NAME  kürze ich im folgenden mit $HOME  ab.
  • Das Arbeitsverzeichnis für den BeagelBone Black lautet:  $HOME/Development/BeagleBone
  • Das Arbeitsverzeichnis für den Raspberry Pi lautet:  $HOME/Development/Raspi

Die Installation der erweiterten Sysroot für den BeagleBone ist dann wie folgt:

Nach dem das Script und dessen zusätzliche Dateien geklont wurde, muss noch die Konfigurationsdatei angepasst werden:

Die folgende Konfigurationsdatei zeigt die Standard Einstellungen für den BeagleBone Black:

Die Bedeutung der einzelnen Parameter sind:

  • SYSROOT_DIR: Ist das Verzeichnis, in das die erweitere Sysroot installiert werden soll. Der Ort kann nach der Installation nicht mehr verändert werden. Das Standart Verzeichnis währe „$HOME/Development/BeagleBone/sysroot“ bzw. „$HOME/Development/Raspi/sysroot“.
  • DOWNLOAD_DIR: Ist das Verzeichnis, in das die Source Paket geladen werden. Es liegt auf der gleichen Ebene wie die Targets, so muss der Download bei verschiedenen Targets nur einmal durchgeführt werden ($HOME/Development/cross-sysroot-downloads).
  • TOOLCHAIN_DIR: Ist das Verzeichnis in dem die jeweiligen Toolchain des Targets liegen.
  • TARGET: Ist der Prefix des Cross Compilers z.B. arm-linux-gnueabihf bei arm-linux-gnueabihf-gcc.
  • BORAD: Ist das Target Board

Sind alle Parameter korrekt, kann mit dem Kompilieren der Sysroot begonnen werden:

Das Erstellen nimmt nun einige Zeit in Anspruch, man hat also zwei oder auch drei Stunden Pause. Ggf. ist es sinnvoll Time Machine für diese Zeit auszuschalten, da sonst alle Source Dateien ein Backup erhalten.

Cross Compiling mit Eclipse CDT

Sofern noch nicht gesehen muss erst einmal Eclipse installiert werden. Ich empfehle Eclipse in der Version Kepler zu installieren und zwar in der 32Bit Variante. Nach der Installation Eclipse öffnen. Ggf. muss noch Java installiert werden, hierzu wird man aber aufgefordert.

Als erstes muss nun des Target eingestellt werden. Es können hier mehrere Targets angelegt werden. Im Menü „Window“ → den Eintrag → „Open Prespective“ → „Other“ wählen.

Eclipse001

In dem Dialog „Remote System Explorer“ (RSE) aktivieren und mit OK bestätigen. Wenn der Welcome Screen geschlossen wird, ist der RSE links dargestellt. Innerhalb des RSE das Kontextmenü aufrufen (Rechtsklick).

Eclipse002

  • Im Dialog „Linux“ wählen und „Next“ drücken.
  • Hostname oder IP-Adresse eingeben und „Next“ drücken.
  • Files: Unter „Configuration“ den Eintrag „ssh.files“ wählen und „Next“ drücken.
  • Processes: Unter „Configuration“ den Eintrag „processes.shell.linux“ wählen und „Next“ drücken.
  • Shells: Unter „Configuration“ den Eintrag „ssh.shells“ wählen und „Next“ drücken.
  • SSH Terminals: Unter „Configuration“ den Eintrag „ssh.terminals“ wählen und „Finish“ drücken.

In die Perspective C/C++ wechseln, Icon oben rechts und ein neues C++ Project anlegen (z.B. hello).

Eclipse004

Als Project Typ „Executable“ → „Empty Project“ und als Toolchain „Cross GCC“ wählen und „Next“ drücken. Der nachfolgende Dialog kann auch gleich mit „Next“ übersprungen werden.

Eclipse005

In Cross GCC Command nun den Cross Compiler Prefix „arm-linux-gnueabihf-“ eingeben und unter Cross Compiler Path den Pfad zu den Toolchain Binaries festlegen, z.B.:

  • BeagleBone: /usr/local/linaro/arm-linux-gnueabihf/bin
  • Raspberry: /usr/local/linaro/arm-linux-gnueabihf-raspbian/bin

Mit Finish den Dialog bestätigen und das Projekt ist angelegt. Mit „File“ → „New“ → „Source File“ eine neue cpp-Datei (z.B. hello.cpp) anlegen und den folgenden Inhalt einfugen:

Mit „Project“  → „Build Project“ oder [cmd+b] kann alles kompiliert werden. Um das Programm auf dem Target auszuführen, wählt man „Run“ → „Run Configurations“. Mit Rechtsklick auf „C/C++ Remote Application“ klicken und im Kontextmenü den Eintrag „New“ wählen. Unter „Main“ den „Remote Absolute File Path for C/C++ Application“, z.B. „/root/hello“. Auf „Apply“ klicken um alles zu übernehmen und mit „Run“ das Programm auf dem Target Starten.

Soll der Debugger zum Einsatz kommen, wählt man „Run“ → „Debug Configurations“. In „Main“ geht man, sofern es nicht übernommen wurde, genau so vor wir bei „Run“. Zusätzlich wählt man noch die Registerkarte „Debugger“ aus und stellt unter „GDB debugger“, den Debugger für das Target „/usr/local/linaro/arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gdb“ ein. Mit „Apply“ alles übernehmen und mit „Debug“ das Programm im Debugmodus auf dem Target ausführen. Hiebei lässt sich nun das Programm Zeile für Zeile ausführen.

Dies basierte nun alles auf Standard C++, der Aufwand mit der Sysroot kommt also noch nicht zum Tragen. Um den gleiche Source wie oben mit Glib zu erstellen, muss Eclipse erst einmal der Ort der erweiterten Sysroot mitgeteilt werden. Rechtsklick auf das Projekt und den Eintrag „Properties“ auswählen. Im Dialog den Eintrag „C/C++ General“ → „Path and Symbols“ auswählen und unter Includes die Schaltfläche „Add“ klicken. Den Pfad zu den Sysroot Includes eingeben.

  • „%HOME/Development/BeagleBone/sysroot/include“
  • „%HOME/Development/BeagleBone/sysroot/include/glib-2.0“
  • „%HOME/Development/BeagleBone/sysroot/lib/glib-2.0/include“

Das Kontrollkästchen „Add to all Languages“ aktivieren und OK klicken. Danach „Library Path“ wählen und den Pfad zu den Sysroot Libs eingeben:

  • „%HOME/Development/BeagleBone/sysroot/lib“

Nun noch die benötigten Libraries eingeben:

  • glib-2.0
  • pthread

Schließe den Dialog und ersetze den zuvor eingegebenen Code mit dem folgenden:

Zugegeben für das Beispiel macht der Aufwand keinen Sinn, der kommt erst bei größeren Projekten zum Tragen.

Cross Compiling mit Qt Creator

Zunächst muss erst einmal der Qt Creator installiert werden. Auch wenn in der Sysroot die Version 4.8.6 installiert wurde kann dennoch der aktuelle Qt Creator 3.2.1 for Mac, der eigentlich für Qt in der Version 5 oder höher bestimmt ist, installiert werden (minimum Qt Creator 2.6.2). Nach erfolgreicher Installation, Qt Creator öffnen und das Menü „Qt Creator“ → „Einstellungen“ aufrufen.

Nun definiert man erstmal ein Gerät, sprich das Target. Dazu links unten „Gerät“ wählen und rechts oben „Hinzufügen“ klicken.

qt001 Im Dialog „Generisches Linux-Gerät“ wählen und auf „Assistenten starten“ klicken.

qt002

Die Verbindungsdaten für das Target eingeben und Weiter drücken.

qt003

Den nachfolgenden Dialog mit „Fertig“ beenden, es erscheint ein Testdialog. Nachdem der Test erfolgreich abgeschlossen ist, auf „Schließen“ drücken.

qt004

Im Hauptdialog, links unten, auf „Anwenden“ drücken um ales zu speichern.

Danach den Eintrag „Erstellung und Ausführen“ wählen und dort auf „Compiler“, „Hinzufügen“ und „GCC“ drücken. Einen beliebigen Namen eingeben und unter Compiler Pfad „/usr/local/linaro/arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++“ eintragen (BeagleBone). Danach links auf Anwenden drücken. Kleiner Tip [cmd+shift+h] zeigt versteckte Dateien an.

Nun auf „Qt Version“ hinzufügen drücken und die entsprechende Qt Version auswählen:

  • /usr/local/Trolltech/Qt-4.8.6-beaglebone/bin/qmake  für BeagleBone
  • /usr/local/Trolltech/Qt-4.8.6-raspi/bin/qmake  für Raspberry Pi

„Debugger“ wählen und den Pfad für den Debugger eingeben:

  • /usr/local/linaro/arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gdb  für BeagleBone
  • /usr/local/linaro/arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-gdb  für Raspberry Pi

Zum Schluss auf „Kits“ drücken und die zuvor getroffenen Parameter einstellen, wie unten abgebildet am Beispiel eines BeagleBone Blacks.

qt005

Bevor wir nun ein Programm erstellen und auf dem Target laufenlassen können, müssen noch einige Modifikationen des Target vorgenommen werden.

Vorbereitung des Targets für Qt

Zum Verständnis, die Qt Version die das Script kompiliert hat, ist die embedded Qt Version mit eigenem Framebuffer. Die Qt Version in den Debian Paketquellen setzt ein Fenstermanager voraus. Dies bedeutet, man kann Qt nicht aus den Paketquellen installieren, sondern es müssen die kompilierten Bibliotheken auf das Target kopiert werden. Nachfolgend am Beispiel des BeagleBone Black:

Damit die Bibliotheken auch gefunden werden, muss der Pfad in die Umgebungsvariable PATH eingetragen werden.

In der Datei die Zeile 5 und 7 durch den Pfad „/usr/local/Trolltech/Qt-4.8.6-beaglebone/lib“ erweitern.

Da die libffi in der Version 6 installiert wurde, die Version 5 ließ sich unter OS X nicht konfigurieren, muss auch diese auf das Target kopiert werden.

Da bei einem frisch installierten BeagleBone Black und auch beim Raspberry Pi bereits ein Window Manager läuft, muss dieser entfernt werden.

Das Target ist nun einsatzbereit.

Qt auf dem Target testen

Nun kann ein Neues Projekt erstellt werden. Dazu „Datei“ → „Neu“ wählen. Im Dialog „Anwendungen“ → „Qt-Widgets-Anwendung“ markieren und in dem Dropdown Menü, oben rechts, Vorlage für Embedded Linux wählen, danach auf den Button „Auswählen“ klicken.

qt006

 

Dem Projekt einen Namen geben (z.B. Demo), im gewünschten Ordner speichern und „Weiter“ drücken. Kleine Empfehlung, legt einen Unterordner, mit dem gleichen Namen wie euer Projekt, an und speichert es darin. Nun kommt das Schöne an Qt Creator, man kann ein und das selbe Projekt für verschiedene Targets und auch den Host PC anlegen und innerhalb des Projektes ganz einfach wechseln. (Weiter zum nächsten Dialog)

qt007

Nun der Klasse noch ein Name gegeben, ich belasse es für die Demonstration bei der Vorgabe „MainWindow“, was man bei einem regulären Projekt niemals machen sollte. Drücke weiter und bestätige den nachfolgenden Dialog mit Fertig.

Es erscheint nun unser Hauptfenster, in dem sich bereits eine Fenster-Anwendung befindet. Durch drücken des Hammers kann und sollte diese kompiliert werden können.

qt008

Hat das funktioniert kann durch drücken auf den grünen Pfeil das Programm auf das Target übertragen und dort ausgeführt werden. Zuvor muss allerdings noch die Projektdatei angepasst werden, so dass sie für das Demo wie folgt aussieht:

Zusätzlich muss noch ein Kommandozeilenargument übergeben werden. Dazu auf „Projekte“ → „Erstellung und Ausführung“  → „Ausführung“ klicken und im Feld „Argumente“ den Parameter „-qws“ eintragen.

qt009

Drückt man nun auf ausführen, sollte die Anwendung auf dem Bildschirm des Targets erscheinen.

Comments

  • Toller Artikel! Vielen Dank auch für das Öffentlich machen deiner Toolchain!! Ich nutze diese zusammen mit Eclipse Luna und direktes Ausführen von Programmen auf dem BeagleBone Black klappt einwandfrei, jedoch kann ich leider nicht debuggen. Ich bekomme hier bei jedem Versuch Fehlermeldung folgender Art:

    Can’t find a source file at „/Users/knut/Development/cross-tools/cross-build/build/src/eglibc-linaro-2.19-2014.05/elf/dl-fini.c“
    Locate the file or edit the source lookup path to include its location.

    oder so:

    Can’t find a source file at „/Users/knut/Development/cross-tools/cross-build/build/arm-linux-gnueabihf/build/build-cc/arm-linux-gnueabihf/libstdc++-v3/include/ostream“
    Locate the file or edit the source lookup path to include its location.

    Zuerst ging ich davon aus das evtl. dem Linker noch ein falsche Pfad zu den Includes zugewiesen ist, jedoch müsste der Pfad korrekt sein. Wäre klasse, wenn du mir weiterhelfen kannst!

    LG,

    Vincent

    Vincent22. November 2014
  • Hallo Vincent,

    das Phänomen hatte ich bislang noch nicht. Weder auf meinem Mac noch auf meinem MacBook existiert die Datei „dl-fini.c“, da ich zum bauen der Toolchain ein Case sensitivit Image verwendet habe.
    Damit ich das richtig verstehe: Der Fehler tritt auf, sobald du „arm-linux-gnueabihf-gdb“ verwendest, um in Eclipse zu debuggen.
    Hast du vielleicht die Möglichkeit, das mit den offiziellen Linaro Toolchain unter Linux zu verifizieren? Oder kannst du mir ein Demo-Projekt zukommen lassen, so dass ich mir das im Detail anschauen kann.

    Gruß

    Knut23. November 2014
  • Hey Knut,

    das ist richtig, ich habe in Eclipse unter den Debug Configurations zu meinem Projekt in dem Tab Debugger den Pfad angegeben, in dem der Debugger liegt (/usr/local/linaro/arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gdb). Eclipse scheint den Debugger auch ausführen zu können, da sich die Debug Perspektive öffnet, will ich aber nun schrittweise durch das Programm gehen kommt es zu bereits genannten Fehlern.

    Unter Linux (ich nutze die Ubuntu 14.04 LTS Distribution) nutze ich momentan gdb-multiarch zusammen mit der arm-linux-gnueabi-Toolchain zum Debuggen innerhalb von Eclipse und hatte damit bis jetzt noch nie Probleme. Ich kann natürlich mal die Toolchain von Linaro testen und dir dann hier noch einmal Rückmeldung geben.

    Ich habe dir ein einfaches „Hello World“ Projekt an die unter Impressum zu findende eMail-Adresse als Zip-Datei geschickt.

    Gruß,

    Vincent23. November 2014
  • Hi,

    I’m following your instructions to the letter. However, I’m getting the following error at dbus step:

    CCLD dbus-launch
    /usr/local/linaro/arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/4.9.1/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lX11
    collect2: error: ld returned 1 exit status
    make[2]: *** [dbus-launch] Error 1
    make[1]: *** [all-recursive] Error 1
    make: *** [all] Error 2

    *** Error in dbus ***

    I have the X11 installed already. So, what is missing?

     

    Thanks,

    –Rasit

    Rasit Eskicioglu2. Dezember 2014
  • Hi Rasti,
    that answers my question to translate this article into english.

    We talk about a installation on Mac OS X?
    And you have installed X11 for OS X or for arm-linux?
    But that does not matter. I think that the configuration script of dbus recognizes the X11 header and tries to build dbus-launch. This does not work because the X11 library is not present for the ARM architecture. But dbus-launch is not required for the sysroot, so my suggestion would be to disable X11 in dbus.

    To do this, go into the folder formula and open the file dbus.sh. Extend the array Args with the element "--without-x".
    It should then be as follows:
    ARGS=(
    "--enable-shared"
    "--disable-static"
    "--program-prefix=${TARGET}-"
    "--host=${HOST}"
    "--sbindir=${BASE_DIR}/tmp/sbin"
    "--libexecdir=${BASE_DIR}/tmp/libexec"
    "--sysconfdir=${BASE_DIR}/tmp/etc"
    "--localstatedir=${BASE_DIR}/tmp/var"
    "--datarootdir=${BASE_DIR}/tmp/share"
    "--without-x"
    )

    I hope this will solve your issue and the error does not occur in another package again.
    Anyway, please let me know, if you have success or not.

    Regards

    Knut2. Dezember 2014
  • It seems installing dbus formula must come after libX11. Sourcing it after libX11 solved the problem, thanks.

    I was wondering if you would consider checking if the filesystem that the build runs is case-sensitive before creating such filesystems. I’m running it on such a file system and I now have a case-sensitive filesystem inside a case-sensitive filesystem, which resides on a mac OS Extended/journaled filesystem… Too many levels…;-)

    –Rasit

    Rasit Eskicioglu2. Dezember 2014
  • Da ich das Problem mit Vincent direkt per Mail erörtert habe, will ich die Lösung hier nicht vorenthalten.

    Der Debugger bietet zwei Möglichkeiten an, „Step Into“ und „Step over“.
    Mit „Step Into“ gelangt man in die Funktion an der sich der Debugger gerade befindet und mit „Step over“ überspringt man die Funktion.
    Handelt es sich nun um eine Funktion die als Bibliothek vorliegt, versucht der Debugger, zumindest bei einigen Funktionen, den Source anzuzeigen.
    Da er aber bereits kompiliert ist kann er die c/cpp-Datei nicht finden und gibt eine Fehlermeldung aus.
    Im obigen Fall war das „cout“. Bei „printf“ taucht das Problem seltsamerweise nicht auf.

    Standart Funktionen also am besten mit „Step over“ überspringen!

    Knut2. Dezember 2014
  • The script has grown over time. At the beginning I didn’t need X11.
    Before I updated my Ubuntu VM from 12.04 auf 14.04, I can use Qt there. After that I could use unity 3d and nothing else.
    I extended the script so that I was able to build Qt embedded on Mac OS X.
    Qt was also the reason to use a case-sensitive filesystem. Whenever I tried to compile Qt, some files were not found which were actually present. So I try to build it in a case-sensitive image and the problem was solved.

    I will try to rearrange the packages. Probably it is also better to build glib after X11.

    Knut

    Knut2. Dezember 2014
  • HI,

    Habe versucht nach deinem Tutorial eclipse fürs cross compilen zu installieren.

    klappt auch soweit.

    jetzt habe ich in meinem project die wiringPi lib und beim linken beschwert eclipse sich das er die

    libpthread.so.0 nicht findet.

    brauche ich die  libpthread.so.0 für den mac kompiliert, oder eine raspberry libpthread.so.0 ?

    Vl. kannst du ja helfen.

    /usr/local/linaro/arm-linux-gnueabihf-raspbian/bin/../lib/gcc/arm-linux-gnueabihf/4.9.1/../../../../arm-linux-gnueabihf/bin/ld: warning: libpthread.so.0, needed by /Users/Christian/raspberry/wiringPi/wiringPi/libwiringpi.so, not found (try using -rpath or -rpath-link)

    vielen dank

    christian16. Dezember 2014
  • Hallo,

    die Pthread Libraries ist in den standard Bibliotheken der Toolchain vorhanden.
    Um sie in Eclipse zu nutzen, musst du die Eigenschaften (Properties) des Projekts öffnen.
    Dann zu „C/C++ General“ -> „Paths and Symbols“ -> „Libraries“ gehen und auf „Add“ drücken.
    Im Dialog „pthread“ einfügen, alle Dialoge schließen, danach sollte alles funktionieren.

    Allerdings müsstest du an der gleichen Stelle schon die libwiringPi eingegeben haben, oder?
    Und wie hast du überhaupt die WiringPi kompiliert?

    Gruß

    Knut17. Dezember 2014
  • Hallo Knut!

    ja cool, hat sofort funktioniert. vielen Dank!

    die wiringPi hatte ich schon eingetragen, da ich es von meinem Windows X-compiler so kannte. Unter Windows und der tool chain von http://www.gurucoding.com/en/rpi_cross_compiler/index.php kam diese Fehlermeldung nie.

    Die wringPi lib selber brauchte ich unter windows nie selber kompilieren. Die habe ich mit dem raspberry kompiliert und dann nach windows bzw. OS X kopiert und in eclipse kenntlich gemacht.

    hast mein Tag gerettet!

    christian

    christian17. Dezember 2014
  • Hallo,
    tolle Anleitung, vielen Dank!
    Habe aktuell auf meinem MBA ein Problem mit dem Kompilieren der advanced sysroot:
    Gebe ich das command „./sysroot-build.sh“ ein, kommt die Meldung:
    Some required applications are not installed!
    You can install them as follows:
      $ brew install gettext

    Führe ich den Befehl aus, so meldet brew:
    „Warning: gettext-0.19.4 already installed“

    Was kann ich machen, um weiterzukommen?

    Sebastian1. März 2015
  • Hallo Sebastian,

    du musst gettext noch linken:
    $ brew link gettext --force

    Danach sollte alles funktionieren.

    Gruß

    Knut4. März 2015
  • Hallo Knut,
    vielen Dank für die Antwort!
    Wenn ich linken will, kommt die Fehlermeldung „/usr/local/linaro/tools/gettext is not a valid keg“

    Gibt es da ein Gegenmittel?
    Viele Grüße,
    Sebastian

    Sebastian10. März 2015
  • Hallo Sebastian,

    bei der Installation wird eine kompilierte Version von gettext mit installiert und gelinkt.
    Ich hatte damit bislang zwar noch keine Probleme, aber muss ich vielleicht doch ändern.
    Versuch mal folgendes, in einem Terminal:

    Lösche den Symbolischen Link:
    $ sudo rm -rf /usr/local/opt/gettext

    Schau nach ob Brew noch weiter Probleme hat:
    $ brew doctor
    Und behebe sie entsprechend der Vorschläge des Doctors.

    Installiere bzw. Reinstalliere eine Universal Version, also sowohl die 64 als auch die 32Bit Bibliothek von gettext:
    $ brew reinstall gettext --universal

    Erstelle die Symbolischen links von gettext neu:
    $ brew link gettext --force

    Jetzt müsste eigentlich alles funktionieren.

    Viel Glück und Gruß

    Knut10. März 2015
  • Japp, läuft großartig!

    Vielen Dank,
    Sebastian

    Sebastian11. März 2015
  • Hallo,

    erstmal Danke für die tolle Anleitung, sie hat mir sehr geholfen!

    Leider komme ich aber nicht weiter. Beim Versuch dein Codebeispiel mit glib zu kompilieren erhalte folgende Fehlermeldung:

    warning: librt.so.1, needed by /Users/Roca/Development/Raspi/sysroot/lib/libglib-2.0.so, not found (try using -rpath or -rpath-link)

    Die Suche nach der Datei war auf meinem Rechner ebenso erfolglos.
    Alle Pfade, Include und Lib, sind wie in deiner Anleitung beschrieben in Eclipse eingetragen worden.

    Ich weiß gerade nicht weiter.

    Vielen Dank

    Johannes

    Johannes24. März 2015
  • Hallo Johannes,

    die Bibliothek liegt unter:
    /usr/local/linaro/arm-linux-gnueabihf/arm-linux-gnueabihf/libc/lib/arm-linux-gnueabi/librt.so.1

    Sie ist ein Bestandteil der Tool Chain, aber das ist eigentlich egal, du must einfach noch „rt“ bei den Libraries hinzufügen. Also dort wo du die Bibliothek „glib-2.0“ und „pthread“ eingetragen hast.
    Immer wenn du eine solche Meldung bekommst, wie bei der „librt.so.1“, lass das „lib“ und das „.so*“ weg und trage das was übrig bleibt in den dialog der Libraries ein.

    Da du im Finder nicht nach allen Dateien suchen kannst, gibt es noch die Möglichkeit über die Konsole bzw. Terminal zu suchen.
    Mal am obigen Beispiel:
    find /usr/local/linaro/arm-linux-gnueabihf-raspbian -name librt*

    Gruß

    Knut24. März 2015
  • Vielen Danke Knut!

    Funktioniert einwandfrei 🙂

    Johannes26. März 2015
  • Hallo Knut,

    ich habe gerade versucht entsprechend der Anleitung alles zu compilen. Jedoch bekomme ich beim Compilieren von QT5 ein Fehler:

    Extract qt-everywhere-opensource-src-5.4.1.tar.gz… donne

    Configure qt-everywhere-opensource-src… donne

    Make qt-everywhere-opensource-src…

    *** Error in qt-everywhere-opensource-src ***

    See ‚/Users/***/Development/Raspi/arm-cross-sysroot/log/qt-everywhere-opensource-src.log‘ for more details

    Cleanup build directory:

    Unmount source image… done

    Renove source image… done

     

    Leider hilft mir die Log dabei nicht weiter, da dort kein Fehler angezeigt wird…Hast du vllt. eine Idee ?

    Philipp Blanke23. April 2015
  • Hallo Philipp,

    ja habe ich. Die Größe des Source Images ist für ein kompletten Durchlauf, mit Qt5, zu klein.
    Ich habe das geändert, nach einem git pull sollte es ohne Probleme durchlaufen.

    Gruß

    Knut23. April 2015
  • Hallo Knut,

    Könnten Sie mir evtl. ein wenig weiterhelfen? Ich habe Ihre Anleitung befolgt, jedoch erhalte ich Fehlermeldungen beim Compilieren in QT. Es tauchen ganz viele „undefined references to ‚png_get_IHDR@PNG16_0′“ oder ähnliche Fehler auf. libQTGui.so scheint wohl libpng16.so.16 zu benötigen, welches jedoch nicht vorhanden ist oder nicht gefunden wird.

    Viele Grüße

    Florian

    Florian3. Juni 2015
  • Hallo Knut,

    ist es möglich auch statt SQLite, MySQL einzubinden ?

    Wenn ja, wie ?

    Vielen Dank

    Alex

    Alexander25. August 2015
  • Hallo Knut,

    ich bekomme folgende Meldung wenn ich versuche mein „Hello World“ Programm auf das Target zu spielen
    Error during file upload.
    Operation failed. File system input or output error
    kannst du mir dabei helfen?
    Vielen Dank
    Matthias

    Matthias13. März 2016

Schreibe einen Kommentar

captcha Gib den CAPTCHA Code ein!