Archiv verlassen und diese Seite im Standarddesign anzeigen : [ERLEDIGT] Problem mit alter LIB GLIBC_2.15, statt GLIBC_2.4
Hallo Zusammen,
ich versuche derzeit den Grund zu finden, warum in meine Programm noch eine alte LIB verwendet wird.
$arm-linux-gnueabi-objdump -x robytask
von libc.so.6 benötigt:
0x06969195 0x00 12 GLIBC_2.15
0x0d696914 0x00 04 GLIBC_2.4
....
0000a10c F *UND* 00000000 __fdelt_chk@@GLIBC_2.15
Hier scheint die Lib "__fdelt_chk" verwendet zu werden, nur den Code in meinem Programm zu finden, gelingt mir nicht.
Kennt jemand dieses Problem.
Viele Grüße
R.
Naja so wie es aussieht scheinst du ja für einen Arm Prozessor kompilieren zu wollen auf dem ein Linux draufläuft. Dein Problem ist nun beim linken oder beim ausführen ? Wenn du crosscompilest solltest du darauf achten, dass du auch auf dem Buildsystem die richtigen abhängigkeiten verfügbar hast.
Hi,
das Problem ist bei der Ausführung.
Gruss R.
Jetzt Rück mal etwas mehr Infos raus. Was hast du für ein System. Crosscompilest du? Welches Linux verwendest du ?
Hi,
sorry.
Ja, ich mache Crosscompiling für einen BeagleBone Black Rev C (Elementary) mit einem Debian Derviat auf ARM.
uname -a
Linux pitbully 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014 armv7l GNU/Linux
Ich verwende kubuntu 14.04 (letzter Stand)
uname -a
Linux ritchie 3.13.0-36-generic #63-Ubuntu SMP Wed Sep 3 21:30:45 UTC 2014 i686 i686 i686 GNU/Linux
mit der Toolchain
arm-linux-gnueabi-g++ -v
COLLECT_GCC=arm-linux-gnueabi-g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabi/4.7/lto-wrapper
Ziel: arm-linux-gnueabi
Konfiguriert mit: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.3-12ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.7.3 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-gnu-unique-object --disable-libmudflap --disable-libitm --enable-plugin --with-system-zlib --enable-objc-gc --with-cloog --enable-cloog-backend=ppl --disable-cloog-version-check --disable-ppl-version-check --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv5t --with-float=soft --disable-werror --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=arm-linux-gnueabi --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include
Thread-Modell: posix
gcc-Version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1)
Hier die Make Datei des System:
GCC_OPTIONS = -W -O03
COMPILER = arm-linux-gnueabi-g++
DEBUG_OPTIONS = -pedantic
#COMPILER = g++
#DEBUG_OPTIONS = -pedantic
#GCC_OPTIONS = -W -g
TARGETNAME = robytask
LINUX_INCLUDE =
LOCAL_INCLUDE = ./include/
LOCAL_OBJ = ./obj/
LOCAL_SRC = ./source/
OBJS = obj/motor.o obj/nav.o obj/path.o obj/coordinate.o \
obj/verhalte.o obj/robyvariable.o obj/robyvariablen.o obj/main.o obj/tcpservm.o \
obj/sensordata.o obj/utility.o obj/roboterpose.o obj/servo.o obj/Logging.o \
obj/i2cbustask.o
all: ${TARGETNAME}
${TARGETNAME}: $(OBJS)
$(COMPILER) -pthread $(GCC_OPTIONS) -L$(LOCAL_OBJ) $(OBJS) -o ${TARGETNAME}
arm-linux-gnueabi-strip ${TARGETNAME}
$(LOCAL_OBJ)robyvariable.o: $(LOCAL_SRC)robyvariable.cpp $(LOCAL_INCLUDE)robyvariable.h
$(COMPILER) $(GCC_OPTIONS) $(DEBUG_OPTIONS) -c -o $(LOCAL_OBJ)robyvariable.o -I$(LOCAL_INCLUDE) $(LOCAL_SRC)robyvariable.cpp
$(LOCAL_OBJ)robyvariablen.o: $(LOCAL_SRC)robyvariablen.cpp $(LOCAL_INCLUDE)robyvariablen.h $(LOCAL_INCLUDE)robyvariable.h
$(COMPILER) $(GCC_OPTIONS) $(DEBUG_OPTIONS) -c -o $(LOCAL_OBJ)robyvariablen.o -I$(LOCAL_INCLUDE) $(LOCAL_SRC)robyvariablen.cpp
$(LOCAL_OBJ)Logging.o: $(LOCAL_SRC)Logging.cpp $(LOCAL_INCLUDE)Logging.h
$(COMPILER) $(GCC_OPTIONS) $(DEBUG_OPTIONS) -c -o $(LOCAL_OBJ)Logging.o -I$(LOCAL_INCLUDE) $(LOCAL_SRC)Logging.cpp
$(LOCAL_OBJ)i2cbustask.o: $(LOCAL_SRC)i2cbustask.cpp $(LOCAL_INCLUDE)i2cbustask.h
$(COMPILER) $(GCC_OPTIONS) $(DEBUG_OPTIONS) -c -o $(LOCAL_OBJ)i2cbustask.o -I$(LOCAL_INCLUDE) $(LOCAL_SRC)i2cbustask.cpp
$(LOCAL_OBJ)motor.o: $(LOCAL_SRC)motor.cpp $(LOCAL_INCLUDE)motor.h $(LOCAL_INCLUDE)robyvariablen.h
$(COMPILER) $(GCC_OPTIONS) $(DEBUG_OPTIONS) -c -o $(LOCAL_OBJ)motor.o -I$(LOCAL_INCLUDE) $(LOCAL_SRC)motor.cpp
$(LOCAL_OBJ)nav.o: $(LOCAL_SRC)nav.cpp $(LOCAL_INCLUDE)nav.h
$(COMPILER) $(GCC_OPTIONS) $(DEBUG_OPTIONS) -c -o $(LOCAL_OBJ)nav.o -I$(LOCAL_INCLUDE) $(LOCAL_SRC)nav.cpp
$(LOCAL_OBJ)path.o: $(LOCAL_SRC)path.cpp $(LOCAL_INCLUDE)path.h
$(COMPILER) $(GCC_OPTIONS) $(DEBUG_OPTIONS) -c -o $(LOCAL_OBJ)path.o -I$(LOCAL_INCLUDE) $(LOCAL_SRC)path.cpp
$(LOCAL_OBJ)roboterpose.o: $(LOCAL_SRC)roboterpose.cpp $(LOCAL_INCLUDE)roboterpose.h
$(COMPILER) $(GCC_OPTIONS) $(DEBUG_OPTIONS) -c -o $(LOCAL_OBJ)roboterpose.o -I$(LOCAL_INCLUDE) $(LOCAL_SRC)roboterpose.cpp
$(LOCAL_OBJ)coordinate.o: $(LOCAL_SRC)coordinate.cpp $(LOCAL_INCLUDE)coordinate.h
$(COMPILER) $(GCC_OPTIONS) $(DEBUG_OPTIONS) -c -o $(LOCAL_OBJ)coordinate.o -I$(LOCAL_INCLUDE) $(LOCAL_SRC)coordinate.cpp
$(LOCAL_OBJ)sensordata.o: $(LOCAL_SRC)sensordata.cpp $(LOCAL_INCLUDE)sensordata.h
$(COMPILER) $(GCC_OPTIONS) $(DEBUG_OPTIONS) -c -o $(LOCAL_OBJ)sensordata.o -I$(LOCAL_INCLUDE) $(LOCAL_SRC)sensordata.cpp
$(LOCAL_OBJ)verhalte.o: $(LOCAL_SRC)verhalte.cpp $(LOCAL_INCLUDE)verhalte.h $(LOCAL_INCLUDE)picdefine.h
$(COMPILER) $(GCC_OPTIONS) $(DEBUG_OPTIONS) -c -o $(LOCAL_OBJ)verhalte.o -I$(LOCAL_INCLUDE) $(LOCAL_SRC)verhalte.cpp
$(LOCAL_OBJ)utility.o: $(LOCAL_SRC)utility.cpp $(LOCAL_INCLUDE)utility.h
$(COMPILER) $(GCC_OPTIONS) $(DEBUG_OPTIONS) -c -o $(LOCAL_OBJ)utility.o -I$(LOCAL_INCLUDE) $(LOCAL_SRC)utility.cpp
$(LOCAL_OBJ)servo.o: $(LOCAL_SRC)servo.cpp $(LOCAL_INCLUDE)servo.h
$(COMPILER) $(GCC_OPTIONS) $(DEBUG_OPTIONS) -c -o $(LOCAL_OBJ)servo.o -I$(LOCAL_INCLUDE) $(LOCAL_SRC)servo.cpp
$(LOCAL_OBJ)main.o: $(LOCAL_SRC)main.cpp $(LOCAL_INCLUDE)main.h $(LOCAL_INCLUDE)robyvariablen.h
$(COMPILER) $(GCC_OPTIONS) $(DEBUG_OPTIONS) -c -o $(LOCAL_OBJ)main.o -I$(LOCAL_INCLUDE) $(LOCAL_SRC)main.cpp
$(LOCAL_OBJ)tcpservm.o: $(LOCAL_SRC)tcpservm.cpp $(LOCAL_INCLUDE)tcpservm.h
$(COMPILER) $(GCC_OPTIONS) $(DEBUG_OPTIONS) -c -o $(LOCAL_OBJ)tcpservm.o -I$(LOCAL_INCLUDE) $(LOCAL_SRC)tcpservm.cpp
dummy:
# Project temp daten loeschen
clean:
rm -f ${LOCAL_OBJ}*.o *~ ${LOCAL_SRC}*~ $(LOCAL_INCLUDE)*~
rm -f ${TARGETNAME}
#/************************************************** *************************/
#/* End of file */
#/************************************************** *************************/
und bekomme zur Laufzeit des Programmes auf der Zielmaschine diese Meldung
$ ./robytask: /lib/arm-linux-gnueabi/libc.so.6: version `GLIBC_2.15' not found (required by ./robytask)
Ich verwendet kdevelop 4.6 für die Entwicklung und habe auch bereits die entsprechenden Include-Datei angelegt, damit ich die korrekten Lib's in der Entwicklung sehe.
Daher mein bestreben, die Programmteile, welche diese LIB verwenden, auf die neue LIB 2.4 zu schreiben. Andere C-Programme arbeiten auf dem System.
Viele Grüße
R.
Sofern ich richtig Informiert bin wird die libc mit der toolchain ausgeliefert (Man kann diese natürlich auch manuell upgraden bzw. dem compiler sagen er soll eine andere Version nehmen) Das einfachste könnte jedoch sein ein upgrade der toolchain zu versuchen.
Hi,
das blöde ist ja, das ich beide verwende. GCLIBC 2.15 und 2.4.
Der Compiler ist meines Wissens laut ubunutu der letzte Stand.
Das Paket ist jedenfalls aktuell.
Nur wenn ich wüsste, welcher Programmteil, welche Funktion noch die alte LIB verwendet, könnte ich das ändern.
Gruss R.
schorsch_76
03.10.2014, 18:56
Crosscompile ist schon möglich... Es ist nicht ganz einfach ... vor allem wenn einem Wissen fehlt wie man Linking Fehler auf dem Target debuggt ;)
Wenn das nur ein robytask ist, gibt es eigentlich keinen Grund das nicht auf dem BBB direkt zu kompilieren. Das ist zumindest meine Empfehlung für dich. Hier speziell.
Zum Crosscompile im allgemeinen braucht man Geduld um die Toolchain aufzusetzen. Man muss _wirklich_ wissen was auf dem Ziel läuft und _wiklich_ wissen was die Toolchain ausspuckt. Es sollte für dich dann auch kein Problem sein, eine eigene Toolchain zu bauen.Das ist meiner Meinung dein Hauptproblem. Deshalb, compiliere lieber auf dem Target selbst...
Wie macht man eine Cross-Toolchain?
http://elinux.org/ARMCompilers
http://www.lowlevel.eu/wiki/ARM_Cross-Compiler
Gruß
Georg
Hi,
danke für die links.
Hatte jedoch schon mehrfach tools für Raspberry PI, taskit Problemlos am rennen.
Ich installiere jetzt die Tools nochmals von neuem.
Normale C Programme arbeiten korrekt.
Habe es fast genauso gemacht. http://www.michaelhleonard.com/cross-compile-for-beaglebone-black/
Gruss R.
Was ist denn genau der Unterschied in deinem Programm im Vergleich zu anderen ?
Hallo,
ist das ein selbst gemachtes Debian ?
Ich habe hier nur Beaglebones mit fertigen Images (von Beagleboard.org oder Robert Nelson). Da weichen zumindest die Compiler-Versionen ab.
Zwei Stichproben:
Linux beaglebone 3.8.13-bone41
gcc version 4.6.3 (Debian 4.6.3-14)
ldd (Debian EGLIBC 2.13-38+deb7u3) 2.13
Ubuntu 14.04.1 LTS (GNU/Linux 3.8.13-bone67 armv7l)
gcc version 4.8.2 (Ubuntu/Linaro 4.8.2-19ubuntu1)
ldd (Ubuntu EGLIBC 2.19-0ubuntu6.3) 2.19
Der gcc 4.7 ist mir beim Beaglebone nur auf den alten Angstöm Images begegnet.
Er verwendet ja den crosscompiler unter einem normalen Debian. Der aktuelle crosscompiler dürfte trotzdem im Moment eigentlich ín Version 4.8 im Repo vorliegen.
Wie aber bereits von meinen Vorpostern gesagt: Kompiliere entweder direkt auf dem Beaglebone oder mach ein update der toolchain bzw. bau sie dir selber.
Was eventuell funktionieren könnte wäre dem Compiler zu sagen er soll eine andere Version der libc verwenden. Man kann nicht in einem Programm mehrere Versionen der libc verwenden. Allein schon weil das linkerfehler geben würde.
Siehe dazu auch:
https://stackoverflow.com/questions/2728552/link-to-a-different-libc-file
Hi,
das Toolchain neu zu installieren, scheint es nicht gebracht zu haben.
Ich werde als nächstes erstmal das aktuelle Image von Debian installieren.
$cat /etc/dogtag
BeagleBoard.org BeagleBone Debian Image 2014-04-23
Aktuelle wäre
Debian (BeagleBone, BeagleBone Black - 2GB SD) 2014-05-14 (http://debian.beagleboard.org/images/bone-debian-7.5-2014-05-14-2gb.img.xz)
@Mxt
>ist das ein selbst gemachtes Debian ?
Das installierte Debian war der Auslieferzustand. Ich verwendet ungerne selbst gemachte OS Versionen, da ich sonst in solche Probleme laufen würde.
Ich könnte auch auf den Compiler (Toolchain) in der Version 4.8 springen, da dieses bereits als Paket vorhanden ist. Wäre der nächste Versuch.
@shedepe
>Was ist denn genau der Unterschied in deinem Programm im Vergleich zu anderen ?
Es ist ein C++ Programm, welche auf Klassen basiert und eine Fülle von Funktionen hat, welche teilweise in den kleinen Testprogrammen (C basierend)
separat korrekt laufen.
Das ist ja gerade das Problem, das ich nicht weiss, welche Funktion mir Ärger macht.
Wenn ich aber die Fehlermeldung jetzt richtig verstehe, ist mein Problem, das hier teile auf der LIB 2.4 arbeiten und die LIB 2.15 halt nicht vorhanden ist,
was mich vermuten läßt, das ich es wohl mal besser mit dem Compiler 4.8 versuche. Insbesondere wo mein Image mal gerade ein Monat älter ist, als die aktuelle Version.
Edit:
auf dem Board ist der folgende Compiler installiert:
$ dpkg --list | grep compiler
ii device-tree-compiler 1.4.0.1~20131212-1 armhf Device Tree Compiler for Flat Device Trees
ii g++ 4:4.6.3-8 armhf GNU C++ compiler
ii g++-4.6 4.6.3-14 armhf GNU C++ compiler
ii gcc 4:4.6.3-8 armhf GNU C compiler
ii gcc-4.6 4.6.3-14 armhf GNU C compiler
Die entsprechende Versionskontrolle zeigt mir auch, das hier der Compiler 4.6.3 verwendet wurde.
$ cat /proc/version
Linux version 3.8.13-bone47 (root@imx6q-wandboard-2gb-0) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Fri Apr 11 01:36:09 UTC 2014
Compiler von hier neu nachgeladen und jetzt schauen wir mal.
Edit2:
gcc-4.6-arm-linux-gnueabihf
deb http://de.archive.ubuntu.com/ubuntu precise main universe
geht immer noch nicht.
Ursache liegt wohl hier, Version des Beagle Bone
$ ldd --version
ldd (Debian EGLIBC 2.13-38+deb7u1) 2.13
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
p
Viele Grüße
R.
schorsch_76
04.10.2014, 18:13
$ cat /proc/version
zeigt die Version des Kernels. Das sagt nichts über das Userland.
Ubuntu und Debian zu mischen ist immer eine schlechte Idee.
Für Debian gibt es eine arm Toolchain
https://wiki.debian.org/EmdebianToolchain
Hi,
meinst Du ich sollte ein Ubuntu Image auch das System flashen ?
Ich update doch erstmals
apt-get update
apt-get upgrade
meine Installation und schaue dann später nochmal rein (Frau ruf ;-) )
Gruss R.
schorsch_76
04.10.2014, 18:23
Hier wird gezeigt wie das mit Debian und Multiarch geht:
https://wiki.debian.org/MultiarchCrossToolchainBuild
Ritchie: Ich kapier einfach nicht warum du nicht einfach auf dem Target kompilierst und auf dem Desktop arbeitest. Das Verzeichnis per NFS oder sshfs (ganz einfach) verbindest, auf dem Desktop programmierst und auf dem Target compilierst. Dann hast du keinerlei Probleme. Dein Robytask wird schon nicht die Größe von LibreOffice haben....
Ob du Ubuntu flashen tust, oder nicht ist deine Entscheidung.
- - - Aktualisiert - - -
Achja, auf dem Target (BBB) machst du einfach
"aptitude install gcc g++ make"
gcc auf arm erzeugt .... arm binaries.... ;)
Mir hat bisher auch immer das Compilieren auf dem Target gereicht. Sogar größere Bibliotheken, wie Poco mit allen Beispielen, lassen sich da bauen.
(Gut, dauert dann ein wenig.)
Vielleicht noch zur Info. Das Image 2014-05-14 von Beaglebone.org ist das stabile Image mit allen Anwendungen drauf.
Hier liegen noch aktuellere Images
http://rcn-ee.net/deb/
in flasher gibt es SD-Karten Images die Debian oder Ubuntu Basissysteme auf den EMMC schreiben,
in microsd Images mit minimalem Debian und Ubuntu zum Start von der Karte
in testing die Entwicklerversion des neuen Beaglebone Images mit Kernel 3.14
Bei allen findet man in /opt/scripts/tools diverse Helferlein, um das Image auf eine komplette Karte auszuweiten,
einen anderen Kernel zu laden, usw.
Hi,
Achja, auf dem Target (BBB) machst du einfach
"aptitude install gcc g++ make"
gcc auf arm erzeugt .... arm binaries.... :wink:
Das habe ich mal gerade ausprobiert und mir war klar, das das geht.
Ist aber was träge. Bis ich die Ursache für mein Problem gefunden habe, könnte ich das als Alternative verwenden.
Hier lese ich derzeit weitere Infos
http://www.little-idiot.de/linuxsolutionguide/doku-libraries.htm
Auf dem Beagle Bone erzeugt
ldd robytask
libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb6f2d000)
libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6ec1000)
libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb6e9d000)
libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6e82000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6d9d000)
/lib/ld-linux-armhf.so.3 (0xb6fe7000)
Auf dem Desktop erzeugt
ldd robytask
./robytask: /lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.15' not found (required by ./robytask)
libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb6e3d000)
libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6dd1000)
libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb6dad000)
libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6d92000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6cad000)
/lib/ld-linux-armhf.so.3 (0xb6ef7000)
Gruss R.
Hallo Zusammen,
das ganze hat mich nicht in Ruhe gelassen. Habe ich doch seit langem immer den Crosscompiler auf dem PC am laufen.
Die Ursache habe ich jetzt jedenfalls gefunden:
Hier die neue Compiler Definitionen (default) verwendet.
GCC_OPTIONS = -W
COMPILER = arm-linux-gnueabihf-g++-4.6
DEBUG_OPTIONS = -pedantic
GCC_STRIP = arm-linux-gnueabihf-strip
Wenn man jedoch diese Option "-O03" aktiviert, wird die neue LIB "GLIBC_2.15" mit eingebunden.
GCC_OPTIONS = -W -O03
Hier das Programm neu auf dem PC erstellt und ldd auf dem BeagleBone ausgeführt.
pi@pitbully:/mnt/projekt/HauptPrg$ ldd robytask
libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb6ee0000)
libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6e74000)
libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb6e50000)
libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6e35000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6d50000)
/lib/ld-linux-armhf.so.3 (0xb6f9a000)
pi@pitbully:/mnt/projekt/HauptPrg$ ./robytask
Start up main program
Main Task started
Viele Grüße
R.
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.