www.mikrocontroller.net

Forum: Compiler & IDEs libusb für ARM -FTDI Treiber


Autor: Torsten Kraus (Firma: IPMS) (kraus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(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).

Autor: Torsten Kraus (Firma: IPMS) (kraus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Torsten Kraus (Firma: IPMS) (kraus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Torsten Kraus (Firma: IPMS) (kraus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Torsten Kraus (Firma: IPMS) (kraus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Torsten Kraus (Firma: IPMS) (kraus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.