4. Cross-Compiling und "Segmentation Fault"

Cross-Compiling und "Segmentation Fault"

  • R

    Hallo Leute,

    ich beiße mir seit ca. 2 Wochen an einem Problem die Zähne aus wo mir langsam die Ideen ausgehen. Also erstmal die Rahmen:
    Ich erstelle mit Hilfe von OpenEmbedded und BitBake Linux Images. OpenEmbedded ist eine Ansammlung von Meta-Daten die Beschreiben wie einzelne Softwarepakete zu übersetzten sind. Darüber hiansu gibt es noch Beschreibungen für die Zeilmaschine wo geregelt welche Architektur das Zielsystem hat und Beschreibungen zur Distribution die Versionsfestelungen macht.
    BitBake verarbeitet diese Informationen und "erstellt" die entsprechenden Softwarepakete. Darüber hinaus erstellt BitBake eine Cross-Compiler Toolchain wenn die Architektur des Build-System von dem des Targets abweicht.

    Nun versuche ich seit ca. 2 Wochen eine Software namens EPICS in dieses System einzufügen. Kompilieren tut alles fehlerlos. Die Software läuft aber nur auf dem Build System nicht jedoch auf dem Target. Dort bricht sie mit einem Segmentation Fault ab.

    Am Anfang dachte ich das beim erstellen gegen die Libraries auf dem Build System gelinkt wird. Nur kann dies, soweit ich die Compiler-Aufrufe richtig verstehe, nicht der Fall sein. Um aber sicher zu gehen das dies wirklich so ist hier mal 2 Auszüge:

    ccache i586-linux-gcc -isystem/root/openembedded/temp/staging/i586-linux/include -fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2 -mar
    ch=i586 -L/root/openembedded/temp/staging/i586-linux/lib -Wl,-rpath-link,/root/openembedded/temp/staging/i586-linux/lib -Wl,-O1 -L../../../lib/linux-x86 -c -
    isystem/root/openembedded/temp/staging/i586-linux/include -D_POSIX_C_SOURCE=199506L -D_POSIX_THREADS -D_XOPEN_SOURCE=500 -D_X86_ -DUNIX -D_BSD_SOU
    RCE -Dlinux -D_REENTRANT -ansi -O3 -Wall -g -fPIC
    -I. -I.. -I../../../src/libCom/bucketLib -I../../../src/libCom/ring
    -I../../../src/libCom/calc -I../../../src/libCom/cvtFast -I../../../src/libCom/cppStd -I../../../src/libCom/cxxTemplates -I../../../src/libCom/dbmf -I../../.
    ./src/libCom/ellLib -I../../../src/libCom/env -I../../../src/libCom/error -I../../../src/libCom/fdmgr -I../../../src/libCom/freeList -I../../../src/libCom/gp
    Hash -I../../../src/libCom/logClient -I../../../src/libCom/macLib -I../../../src/libCom/misc -I../../../src/libCom/osi -I../../../src/libCom/taskwd -I../../.
    ./src/libCom/timer -I../../../src/libCom/tsDefs -I../../../include/os/Linux -I../../../include ../../../src/libCom/dbmf/dbmf.c

    ccache i586-linux-g++ -isystem/root/openembedded/temp/staging/i586-linux/include -fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2 -fpe
    rmissive -march=i586 -L/root/openembedded/temp/staging/i586-linux/lib -Wl,-rpath-link,/root/openembedded/temp/staging/i586-linux/lib -Wl,-O1 -L../../../lib/l
    inux-x86 -c -isystem/root/openembedded/temp/staging/i586-linux/include -D_POSIX_C_SOURCE=199506L -D_POSIX_THREADS -D_XOPEN_SOURCE=500 -D_X86_ -DUNI
    X -D_BSD_SOURCE -Dlinux -D_REENTRANT -ansi -O3 -Wall -g -fPIC
    -I. -I.. -I../../../src/libCom/bucketLib -I../../../
    src/libCom/ring -I../../../src/libCom/calc -I../../../src/libCom/cvtFast -I../../../src/libCom/cppStd -I../../../src/libCom/cxxTemplates -I../../../src/libCo
    m/dbmf -I../../../src/libCom/ellLib -I../../../src/libCom/env -I../../../src/libCom/error -I../../../src/libCom/fdmgr -I../../../src/libCom/freeList -I../../
    ../src/libCom/gpHash -I../../../src/libCom/logClient -I../../../src/libCom/macLib -I../../../src/libCom/misc -I../../../src/libCom/osi -I../../../src/libCom/
    taskwd -I../../../src/libCom/timer -I../../../src/libCom/tsDefs -I../../../include/os/Linux -I../../../include ../../../src/libCom/osi/os/default/epi
    csSocketConvertErrnoToString.cpp

    Die nächste Überlegung war das u.U. doch für den falschen Prozessor übersetzte wird. (Auf dem Zielsystem ist eine Geode CPU die einem i586 entspricht einige Befehle des i686 nicht beherrscht). Aber auch ein -March=i586 hat nicht geholfen.

    Als letztes wollte ich versuchen die Software auf dem Target zu übersetzten. Aber auch das von BitBake erstellte Make bricht mit einem Segmentation Fault ab. Das make was auf meiner Build Maschine läuft (Debian Sarge) bricht ebenfalls mit einem Segmentation fault ab.

    Als glibc wird die Version 2.3.2 auf Build sowie Target verwendet.
    Als gcc wird auf auf dem Target Version 3.3.4 und auf dem Build System 3.3.5 verwendet.

    Wie gesagt wird gehen langsam die Ideen aus was man noch probieren kann bzw. ich befürchte immermehr das bestimmte Libs auf dem Target einfach fehlerhaft sind.

    Würde mich über neue Denkanstöße freuen.

    Gruß,

    ich

    0
  • J

    ... so mal ein paar Ideen, um sich langsam heranzutasten:

    (1) Irgendwie gibt es auch eine Option, mit der automatisch shared Libraries beim Linken herangezogen werden. Habe ich selber auch noch nicht mit gearbeitet. Schau mal unter ldconfig(8) in den Linux Manuals. Irgendwie werden die shared libraries hiermit in einem globalen Konfigurations-File eingetragen...

    (2) Ich halte es für äußerst sinnvoll, sich mal den core-File auf dem target anzusehen (so mach ich das denn immer). Beim Segmentation-Fault sollte irgendwo ein passender core liegen (ggf. muss das Erzeugen eines cores erst noch allgemein aktiviert werden). Wenn kein core da ist, versuch einfach mal mit einem Dummy-Programm (Division durch 0) einen core zu erzeugen, um zu checken, ob cores überhaupt erzeugt werden. Mit Hilfe des cores und dem gdb kannst Du dann (sogar auf dem Build-System) Dir den Stack-Backtrace des Targets ansehen und erkennst i.d.R. sofort, wo das Programm abgeschmiert ist. Damit kommst Du evtl. auch eine Information, ob eine andere Library angesprochen wird. Da Du mit der Option "-g" übersetzt, sollten auch alle Informationen für einen symbolischen Backtrace vorhanden sein. Die Option "-O2" solltest Du dann allerdings entfernen (maximal nur -O benutzen), da der Optimizer teilweise den ausführbaren Code so verändert, dass man den Programmfluss (beim schrittweisen debuggen) einfach schlecht nachvollziehen kann.
    Ach ja: Prinzipiell solltest Du den Code auch auf dem target mit dem gdb schtittweise oder mit Breakpoints ausführen können, wenn denn der da vorhanden ist.

    Keine Bange, ist zwar schwierig, aber das kriegen wir schon raus 😉 Ich würde mal mit Schritt (2) anfangen.

    P.S.: Was bedeutet der Befehl ccache?? Ich habe das mal als so etwas wie den gcc interpretiert. Alle einzelnen Optionen habe ich mir im Detail aber noch nicht angesehen.

    0
  • C

    Dieser Thread wurde von Moderator/in kingruedi aus dem Forum Linux/Unix in das Forum Compiler-Forum verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.

    0
Anmelden zum Antworten