Hallo Comunity, Meine Aufgabe ist es ein Gerät mit integrierten FTDI-Chip an ein Modul(DIMM-RM 9200 http://www.garz-fricke.com/render.php?sess_pid=267) das in ein Testboard integriert ist anzusprechen. Für die Komunikation will ich einen FTDI Treiber benutzen.Dieser unterstütz leider keinen ARM und auch keine 64bit AMD Architektur. 1. Für den ersten Testlauf habe ich mein PC genutz und die libftdi und libusb. Dazu habe ich die Source aus der libftdi genommen und die libusb Libary in mein Projekt eingebunden. Hier funktioniert alles sehr gut. 2.Als zweiten Schritt habe ich mein Compiler auf 32bit Architektur umgestellt.(-m32 ergänzt) Fehlermeldung: /usr/bin/ld: skipping incompatible /usr/lib64/libusb.so when searching for -lusb /usr/bin/ld: skipping incompatible /usr/lib64/libusb.a when searching for -lusb /usr/bin/ld: cannot find -lusb Wie erwartet funktioniert die Libary für 64bit, nicht für eine 32bit Architektur. 3.Nun wollte ich das ganze auf dem Board(DIMM-RM 9200) test. Dazu habe ich die gleiche Source benutzt und natürlich den ARM-Compiler(ARM 2007q1-21 http://www.codesourcery.com/gnu_toolchains/arm/download.html) Aber das funktioniert nicht! Und es gibt maßig Fehler. Fehlerauszug: ../src/ftdi.c:31:17: warning: usb.h: No such file or directory ../src/ftdi.c:128: error: expected declaration specifiers or '...' before 'usb_dev_handle' ../src/ftdi.c: In function 'ftdi_set_usbdev': usw. Für mich sieht es so aus, als das die libusb nicht verwendet wird. Weil die usb.h ja nicht gefunden werden kann. Liege ich damit richtig? 4.Zum Schluß wollte ich die libusb, die ja als Sourcecode mitgeliefert wird in mein Arbeitsverzeichnis kopieren. Wenn ich die Header meiner Main und aller verwendeten Header umstelle. So das sie jetzt aus mein Verzeichnis genommen werden. Dann werden aber andere Header vom System nicht gefunden. Dadurch ist das kein Lösungsansatz. Hat jemand Ideen oder Vorschläge, wie ich die libusb mit ARM-Compiler zum laufen zubringen kann. Oder würde die libusb die man herinterladen kann das Problem lösen, diese könnte ich dann in mein System für die 32bit Libarys integrieren???? Hat jemand Erfahrung mit libusb auf 32bit Architekturen oder sogar libusb auf 32bit ARM? PS: Hier sind erstmal paar Systemdaten: IDE: Eclipse mit GCC-Compiler für PC und ARM 2007q1-21-Compiler für ARM. Auf dem ARM läuft Linux deshalb brauche ich nur ein Makefile. % uname -a Linux linpcm133.ipms.fraunhofer.de 2.6.9-42.0.10.EL #1 Tue Feb 27 09:18:57 EST 2007 x86_64 x86_64 x86_64 GNU/Linux % cat /etc/redhat-release CentOS release 4.4 (Final) % rpm -qa|grep gcc libgcc-3.4.6-3.1 gcc-c++-3.4.6-3.1 compat-gcc-32-c++-3.2.3-47.3 gcc-3.4.6-3.1 gcc4-gfortran-4.1.0-18.EL4.3 compat-libgcc-296-2.96-132.7.2 compat-gcc-32-3.2.3-47.3 gcc4-c++-4.1.0-18.EL4.3 gcc-java-3.4.6-3.1 gcc4-4.1.0-18.EL4.3 gcc-objc-3.4.6-3.1 gcc-g77-3.4.6-3.1 libgcc-3.4.6-3.1 gcc-gnat-3.4.6-3.1 Ich hoffe das ich genügend Daten angegeben habe.
(Was gibt's für einen Grund, einen neuen Thread zu beginnen?) Hör' doch bitte mal auf, mit all dem "unterstützt kein 64 bit"-Kram. Du hast den Sourcecode, bitte compiliere alles für das jeweils natürliche Format deines Zielprozessors. Wenn du auf einem AMD 64 arbeitest, dann hör auf, mit -m32 zu basteln. Das bringt dir nichts. Wenn sich der Sourcecode für einen 64-bittigen Prozessor nicht sauber compilieren lässt, dann steck deinen Fleiß bitte hinein, das zu reparieren, statt endlos weiter nach 32-bit-Workarounds zu suchen. Aber so, wie ich das lese (dein Schritt 1) funktioniert ja alles. Schritt 2 ist überflüssig und völlig unnütz. Die Fehlermeldungen von Schritt 3 deuten darauf hin, dass du für deine Zielplattform (ARM) die libusb nicht so installiert hast, wie es der Compiler erwartet hätte. Da es sich um einen Crosscompiler handelt, erwartet er sowohl die Headerfiles als auch natürlich die binären Bibliotheken (die ja komplett andere sind als die des Hostsystems) in seinen eigenen Verzeichnissen. Welche das sind, das musst du mal selbst erkunden. Tipp: wenn du -v in die GCC-Kommando- zeile mit aufnimmst, dann erzählt er dir, wo er überall sucht. Ich weiß nicht, wie dein Zielbetriebssystem organisiert ist. Wenn es shared libs verwendet (Suffix .so bzw. .so.*), dann musst du natürlich auch die passende ARM-libusb-shared lib (und libftdi genauso) nicht zur zum Linken dem Crosscompiler zur Verfügung stellen, sondern auch im Zielsystem installieren. Falls alles statisch gelinkt wird (keine .so-Dateien im Zielsystem vorhanden), dann sollte dein Crosscompiler am besten auch gar keine .so's erst sehen, sondern nur statische Bibliotheken (Suffix .a).
Danke für die Info, Das mit der -v Ergänzung habe ich gemacht, aber leider blicke ich da überhaupt nicht durch. kleiner Auszug: #include "..." search starts here: #include <...> search starts here: /export/scratch/arm-2007q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/i nclude /export/scratch/arm-2007q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/i nclude-fixed /export/scratch/arm-2007q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/. ./../../../arm-none-linux-gnueabi/include /export/scratch/arm-2007q1/bin/../arm-none-linux-gnueabi/libc/usr/includ e End of search list. Sind das die 4 Verzeichnisse wo mein Compiler nach Libaries sucht? Und reicht es aus die Libarie in ein Verzeichnis zukopieren. Oder muss ich in ein Verzeichnis die Libary hin installieren und dann welches?
Du verwechseltst gedanklich erstmal library (also .a oder .so) und Headerfile (.h, also hier usb.h). Das da ist der Suchpfad für die Headerdateien. Die ersten drei scheinen mir zum Compiler zu gehören, deine usb.h sollte also in der letzten stehen. Wenn du die Punkte auflöst, landest du bei /export/scratch/arm-2007q1/arm-none-linux-gnueabi/libc/usr/include Alternativ kannst du den Standort des Headerfiles immer mit -I angeben. Wenn er das dann compilieren konnte und linken will, wirst du nochmal einen ähnlichen Suchpfad für die Binärbibliotheken finden. Dort gilt dann analog, dass die libusb.a (bzw. libusb.so, falls dynamische Bibliotheken benutzt werden) im entsprechenden Verzeichnis stehen muss, oder aber das Verzeichnis mit -L benannt werden muss, in dem zusätzlich zu suchen ist.
OK ich denke ich habe die usb.h in das richtige(dein angegebenes Verzeichnis)hinein kopiert. ----------------Jetzt kommt diese Konsolenmeldung:---------------------- **** Build of configuration Debug_ARM for project Test **** make -k all Building file: ../find_all.c Invoking: GCC C Compiler /export/scratch/arm-2007q1/bin/arm-none-linux-gnueabi-gcc -O0 -g3 -Wall -c -fmessage-length=0 -v -MMD -MP -MF"find_all.d" -MT"find_all.d" -o"find_all.o" "../find_all.c" Using built-in specs. Target: arm-none-linux-gnueabi Configured with: /scratch/paul/lite/src/gcc-4.2/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-linux-gnueabi --enable-shared --enable-threads --disable-libmudflap --disable-libssp --disable-libgomp --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --prefix=/opt/codesourcery --enable-languages=c,c++ --enable-symvers=gnu --enable-__cxa_atexit --with-versuffix=CodeSourcery Sourcery G++ Lite 2007q1-21 --with-pkgversion=CodeSourcery Sourcery G++ Lite 2007q1-21 --with-bugurl=https://support.codesourcery.com/GNUToolchain/ --disable-nls --with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc --with-build-sysroot=/scratch/paul/lite/install/arm-none-linux-gnueabi/l ibc --enable-poison-system-directories --with-build-time-tools=/scratch/paul/lite/install/arm-none-linux-gnueab i/bin --with-build-time-tools=/scratch/paul/lite/install/arm-none-linux-gnueab i/bin Thread model: posix gcc version 4.2.0 20070413 (prerelease) (CodeSourcery Sourcery G++ Lite 2007q1-21) /export/scratch/arm-2007q1/bin/../libexec/gcc/arm-none-linux-gnueabi/4.2 .0/cc1 -quiet -v -iprefix /export/scratch/arm-2007q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/ -isysroot /export/scratch/arm-2007q1/bin/../arm-none-linux-gnueabi/libc -MMD find_all.dfind_all.o -MFfind_all.d -MP -MTfind_all.d -MQ find_all.o -dD ../find_all.c -quiet -dumpbase find_all.c -auxbase-strip find_all.o -g3 -O0 -Wall -version -fmessage-length=0 -o /tmp/ccWppFk3.s ignoring nonexistent directory "/export/scratch/arm-2007q1/bin/../arm-none-linux-gnueabi/libc/usr/local /include" ignoring duplicate directory "/export/scratch/arm-2007q1/bin/../lib/gcc/../../lib/gcc/arm-none-linux- gnueabi/4.2.0/include" ignoring duplicate directory "/export/scratch/arm-2007q1/bin/../lib/gcc/../../lib/gcc/arm-none-linux- gnueabi/4.2.0/include-fixed" ignoring duplicate directory "/export/scratch/arm-2007q1/bin/../lib/gcc/../../lib/gcc/arm-none-linux- gnueabi/4.2.0/../../../../arm-none-linux-gnueabi/include" #include "..." search starts here: #include <...> search starts here: /export/scratch/arm-2007q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/i nclude /export/scratch/arm-2007q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/i nclude-fixed /export/scratch/arm-2007q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/. ./../../../arm-none-linux-gnueabi/include /export/scratch/arm-2007q1/bin/../arm-none-linux-gnueabi/libc/usr/includ e End of search list. GNU C (CodeSourcery Sourcery G++ Lite 2007q1-21) version 4.2.0 20070413 (prerelease) (arm-none-linux-gnueabi) compiled by GNU C version 3.4.4. GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128112 Compiler executable checksum: 2a67eb7217b732743350e8a18796f97f ../find_all.c: In function 'main': ../find_all.c:30: warning: passing argument 3 of 'ftdi_usb_get_strings' from incompatible pointer type /export/scratch/arm-2007q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/. ./../../../arm-none-linux-gnueabi/bin/as -meabi=4 -ofind_all.o /tmp/ccWppFk3.s Finished building: ../find_all.c Building file: ../src/ftdi.c Invoking: GCC C Compiler /export/scratch/arm-2007q1/bin/arm-none-linux-gnueabi-gcc -O0 -g3 -Wall -c -fmessage-length=0 -v -MMD -MP -MF"src/ftdi.d" -MT"src/ftdi.d" -o"src/ftdi.o" "../src/ftdi.c" Using built-in specs. Target: arm-none-linux-gnueabi Configured with: /scratch/paul/lite/src/gcc-4.2/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-linux-gnueabi --enable-shared --enable-threads --disable-libmudflap --disable-libssp --disable-libgomp --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --prefix=/opt/codesourcery --enable-languages=c,c++ --enable-symvers=gnu --enable-__cxa_atexit --with-versuffix=CodeSourcery Sourcery G++ Lite 2007q1-21 --with-pkgversion=CodeSourcery Sourcery G++ Lite 2007q1-21 --with-bugurl=https://support.codesourcery.com/GNUToolchain/ --disable-nls --with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc --with-build-sysroot=/scratch/paul/lite/install/arm-none-linux-gnueabi/l ibc --enable-poison-system-directories --with-build-time-tools=/scratch/paul/lite/install/arm-none-linux-gnueab i/bin --with-build-time-tools=/scratch/paul/lite/install/arm-none-linux-gnueab i/bin Thread model: posix gcc version 4.2.0 20070413 (prerelease) (CodeSourcery Sourcery G++ Lite 2007q1-21) /export/scratch/arm-2007q1/bin/../libexec/gcc/arm-none-linux-gnueabi/4.2 .0/cc1 -quiet -v -iprefix /export/scratch/arm-2007q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/ -isysroot /export/scratch/arm-2007q1/bin/../arm-none-linux-gnueabi/libc -MMD ftdi.dsrc/ftdi.o -MFsrc/ftdi.d -MP -MTsrc/ftdi.d -MQ src/ftdi.o -dD ../src/ftdi.c -quiet -dumpbase ftdi.c -auxbase-strip src/ftdi.o -g3 -O0 -Wall -version -fmessage-length=0 -o /tmp/ccocslso.s ignoring nonexistent directory "/export/scratch/arm-2007q1/bin/../arm-none-linux-gnueabi/libc/usr/local /include" ignoring duplicate directory "/export/scratch/arm-2007q1/bin/../lib/gcc/../../lib/gcc/arm-none-linux- gnueabi/4.2.0/include" ignoring duplicate directory "/export/scratch/arm-2007q1/bin/../lib/gcc/../../lib/gcc/arm-none-linux- gnueabi/4.2.0/include-fixed" ignoring duplicate directory "/export/scratch/arm-2007q1/bin/../lib/gcc/../../lib/gcc/arm-none-linux- gnueabi/4.2.0/../../../../arm-none-linux-gnueabi/include" #include "..." search starts here: #include <...> search starts here: /export/scratch/arm-2007q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/i nclude /export/scratch/arm-2007q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/i nclude-fixed /export/scratch/arm-2007q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/. ./../../../arm-none-linux-gnueabi/include /export/scratch/arm-2007q1/bin/../arm-none-linux-gnueabi/libc/usr/includ e End of search list. GNU C (CodeSourcery Sourcery G++ Lite 2007q1-21) version 4.2.0 20070413 (prerelease) (arm-none-linux-gnueabi) compiled by GNU C version 3.4.4. GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128112 Compiler executable checksum: 2a67eb7217b732743350e8a18796f97f ../src/ftdi.c: In function 'ftdi_write_data': ../src/ftdi.c:695: warning: pointer targets in passing argument 3 of 'usb_bulk_write' differ in signedness ../src/ftdi.c: In function 'ftdi_read_data': ../src/ftdi.c:779: warning: pointer targets in passing argument 3 of 'usb_bulk_read' differ in signedness ../src/ftdi.c: In function 'ftdi_read_eeprom': ../src/ftdi.c:1224: warning: pointer targets in passing argument 6 of 'usb_control_msg' differ in signedness /export/scratch/arm-2007q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/. ./../../../arm-none-linux-gnueabi/bin/as -meabi=4 -osrc/ftdi.o /tmp/ccocslso.s Finished building: ../src/ftdi.c Building target: Test Invoking: GCC C++ Linker /export/scratch/arm-2007q1/bin/arm-none-linux-gnueabi-g++ -v -o"Test" ./find_all.o ./src/ftdi.o -lusb Using built-in specs. Target: arm-none-linux-gnueabi Configured with: /scratch/paul/lite/src/gcc-4.2/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-linux-gnueabi --enable-shared --enable-threads --disable-libmudflap --disable-libssp --disable-libgomp --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --prefix=/opt/codesourcery --enable-languages=c,c++ --enable-symvers=gnu --enable-__cxa_atexit --with-versuffix=CodeSourcery Sourcery G++ Lite 2007q1-21 --with-pkgversion=CodeSourcery Sourcery G++ Lite 2007q1-21 --with-bugurl=https://support.codesourcery.com/GNUToolchain/ --disable-nls --with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc --with-build-sysroot=/scratch/paul/lite/install/arm-none-linux-gnueabi/l ibc --enable-poison-system-directories --with-build-time-tools=/scratch/paul/lite/install/arm-none-linux-gnueab i/bin --with-build-time-tools=/scratch/paul/lite/install/arm-none-linux-gnueab i/bin Thread model: posix gcc version 4.2.0 20070413 (prerelease) (CodeSourcery Sourcery G++ Lite 2007q1-21) /export/scratch/arm-2007q1/bin/../libexec/gcc/arm-none-linux-gnueabi/4.2 .0/collect2 --sysroot=/export/scratch/arm-2007q1/bin/../arm-none-linux-gnueabi/libc --eh-frame-hdr -dynamic-linker /lib/ld-linux.so.3 -X -m armelf_linux_eabi -oTest /export/scratch/arm-2007q1/bin/../arm-none-linux-gnueabi/libc/usr/lib/cr t1.o /export/scratch/arm-2007q1/bin/../arm-none-linux-gnueabi/libc/usr/lib/cr ti.o /export/scratch/arm-2007q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/c rtbegin.o -L/export/scratch/arm-2007q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0 -L/export/scratch/arm-2007q1/bin/../lib/gcc -L/export/scratch/arm-2007q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0 /../../../../arm-none-linux-gnueabi/lib -L/export/scratch/arm-2007q1/bin/../arm-none-linux-gnueabi/libc/lib -L/export/scratch/arm-2007q1/bin/../arm-none-linux-gnueabi/libc/usr/lib ./find_all.o ./src/ftdi.o -lusb -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /export/scratch/arm-2007q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/c rtend.o /export/scratch/arm-2007q1/bin/../arm-none-linux-gnueabi/libc/usr/lib/cr tn.o /export/scratch/arm-2007q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/. ./../../../arm-none-linux-gnueabi/bin/ld: cannot find -lusb collect2: ld returned 1 exit status make: *** [Test] Error 1 make: Target `all' not remade because of errors. Build complete for project Test Es tut mir Leid das ich so wenig Ahnung habe, aber kannst du mir verraten wo ich die Libary hineinkopieren muss. Alle Versuche haben nicht funktioniert.
Vielleicht solltest du ja besser mit -I und -L arbeiten.
Die beiden Verzeichnisse kämen für die libusb.a in Frage, wenn du
sie in einem Systemverzeichnis unterbringen willst:
/export/scratch/arm-2007q1/arm-none-linux-gnueabi/libc/lib
/export/scratch/arm-2007q1/arm-none-linux-gnueabi/libc/usr/lib
> Alle Versuche haben nicht funktioniert.
Besser wäre es hier zu beschreiben, was genau du denn versucht hast.
Folgendes habe ich probiert: in "/export/scratch/arm-2007q1/arm-none-linux-gnueabi/libc/usr/lib" habe ich die Libaries(*.so und *.a) hinein kopiert. Wenn ich mein Programm ausführe kommt das: Fehlerauszug: /export/scratch/arm-2007q1/arm-none-linux-gnueabi/libc/usr/lib/libusb.so : file not recognized: File format not recognized Und wenn ich die *.so herazslösche dann kommt folgendes: /export/scratch/arm-2007q1/arm-none-linux-gnueabi/libc/usr/lib/libusb.a: could not read symbols: File format not recognized In diesem Verzeichnis sind *.so und *.a Datein drin, könnte also der richtige Platz sein. Aber ich weis nicht warum meine Libary ein falsches Format hat. >Vielleicht solltest du ja besser mit -I und -L arbeiten. Und was meínst du mir -I und -L arbeiten?Muss ich das an ein Verzeichnis heran hängen? (-I ist für den Libary-Namen und -L für den Libary-Pfad?) >Die beiden Verzeichnisse kämen für die libusb.a in Frage, wenn du >sie in einem Systemverzeichnis unterbringen willst: Wie meinst du das?
Torsten Kraus wrote: > Aber ich weis nicht warum meine Libary ein falsches Format hat. Vermutlich, weil du dort die Binärbibliotheken hineinkopiert hast, die du nicht für den ARM, sondern für den AMD64 gebaut hast. Das geht natürlich nicht, wie ich dir den ganzen Thread lang schon versuche begreiflich zu machen... >>Vielleicht solltest du ja besser mit -I und -L arbeiten. > Und was meínst du mir -I und -L arbeiten? Muss ich das an ein > Verzeichnis heran hängen? Nein, mit -I gibst du den Pfad zu zusätzlichen Include-Dateien an (wie usb.h), also das Verzeichnis, in dem der Compiler diese suchen soll. Mit -L gleiches für die (binären) Objektmodulbibliotheken (also .a und .so). > (-I ist für den Libary-Namen und -L für den Libary-Pfad?) Nein, -L für den Pfad, -l für den Namen. Der Namen wird dabei um "lib" und um die Suffixe ".so" oder ¨.a" erweitert, d. h. mit -lusb wird nach einer Datei libusb.so und einer libusb.a gesucht (in dieser Reihenfolge). Die Angabe von sowohl -I (beim Compilieren) als auch -L (beim Linken) erspart es damit, dass man die entsprechenden Header und Libs in exakt die Verzeichnisse kopieren muss, in denen der Compiler nach den Systembibliotheken sucht. Sorry, aber du machst keinerlei Anstalten, auch nur ein einziges Mal selbst einen Blick in die man page deines Compilers zu werfen. Ich bin kurz davor, die Sache hier aufzugeben und anderen zu überlassen, dir weiterzuhelfen, wenn sie nur wollen.
Zum einen habe ich mich mit den Compiler aus einander gesetzt und in den PDF's steht nichts dazu drin. Die Sache mit den Ergänzungen bewirken nichts, da diese automatisch von der IDE ergänzt werden und wenn ich es manuel mache dann steht es doppelt da. Und nach den Fehlermeldungen zufolge sucht der Linker auch in den richtigen Verzeichnissen. Ich habe nur die normalen Datein/Libary(die von der Website). Ich denke auch nicht das ich so weiter komme. Verständnis Frage: Was ich nicht verstehen kann ist, das es so große Probleme gibt. Ich dachte das der Treiber "nur" API's zur Verfügung stellt die wiederum auf System Libaries zugreifen da auf dem ARM ja Linux läuft und ich kann deswegen einen normalen Linux Treiber(der für einen PC) nehmen. Wie ich es von dir immer höre, muss ich den "normalen" Linux-Treiber für einen ARM umschrieben/compilieren. Weil die Binärbibiliothek falsch ist? Was macht ein Binärbiliothek(finde nicht viel bei googel)? Fazit: Also doch Treiber neu-/umschreiben, also neu compelieren????? Ich wollte mich für die tatkräftige Unterstützung bedanken, auch wenn es ich über haupt keine Ahnung hatte.
Binärbibliotheken enthalten compilierten Programmcode. Und der unterscheidet sich von Prozessor- zu Prozessorarchitektur, und zwar ganz erheblich. Du scheinst zu versuchen, mit einem ARM-Compiler Libraries für x86/x64 zu verwenden. Das geht nicht. Ein ARM versteht keinen x86/x64-Code. Damit Du die Libraries verwenden kannst, musst Du Dir deren Quelltext besorgen und sie mit dem ARM-Compiler übersetzen, also die entsprechenden lib*.a resp. *.so-Dateien selber erzeugen.
Ahh Ok. Einen ARM-Compiler habe ich ja und ich werde mal suchen wie man solche Libary Dateib erzeugt. Vielen Dank für die INFO! Und dann bringt mir auch das Linux auf dem ARM was, wenn ich die libusb in ein für den ARM umgewandelte Libary habe.
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.