Forum: Compiler & IDEs libusb für Linux auf ARM9 (Centipad)


von Michael P. (michael_p)


Lesenswert?

Hallo!

Ich versuche verzweifelt libusb auf meinem ARM9 Board (Centipad) zum 
Laufen zu brigen. Leider habe ich nicht genug Linux Know-How, vielleicht 
kann mir ja Jemand weiterhelfen.

libusb kann ich tadellos auf dem Host (für den Host) übersetzen und dort 
ist es auch lauffähig.

Meine vermutlich naive Annahme war nun dass ich wiefolgt für den 
Cross-Compiler vorgehn kann:
Konfiguration mit "./configure --target=ARM-linux"
danach noch im makefile das
CC = gcc
gegen
CC = arm-920t-linux-gnu-gcc
ersetzen und mit make übersetzen.

Das scheint auch für libusb zu funktionieren.
Zusätzlich gibt es ja bei libusb das schöne Testprogramm lsusb welches 
sich im /examples Unterordner befindet. Da habe ich im Makefile auch CC 
= arm-920t-linux-gnu-gcc eingetragen.
Probiere ich dieses zu übersetzen (um einen einfachen Test der 
Lauffähigkeit von libusb zu haben) erhalte ich folgende Fehlermeldung.
1
michael@michael-VirtualBox:~/CentiDev-1.2.0b_KW/app/libusb-1.0.8/examples$ make
2
  CC     lsusb.o
3
  CCLD   lsusb
4
../libusb/.libs/libusb-1.0.so: could not read symbols: Invalid operation
5
collect2: ld returned 1 exit status
6
make: *** [lsusb] Error 1

detailierter sieht das so aus:
1
michael@michael-VirtualBox:~/CentiDev-1.2.0b_KW/app/libusb-1.0.8/examples$ make V=1
2
arm-920t-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I..    -g -O2 -MT lsusb.o -MD -MP -MF .deps/lsusb.Tpo -c -o lsusb.o lsusb.c
3
mv -f .deps/lsusb.Tpo .deps/lsusb.Po
4
/bin/bash ../libtool  --tag=CC   --mode=link arm-920t-linux-gnu-gcc  -g -O2   -o lsusb lsusb.o ../libusb/libusb-1.0.la -lusb-1.0 -lrt 
5
libtool: link: arm-920t-linux-gnu-gcc -g -O2 -o .libs/lsusb lsusb.o  ../libusb/.libs/libusb-1.0.so -lrt -pthread
6
../libusb/.libs/libusb-1.0.so: could not read symbols: Invalid operation
7
collect2: ld returned 1 exit status
8
make: *** [lsusb] Error 1

../libusb/.libs/libusb-1.0.so ist vorhanden und zeigt auf:
1
michael@michael-VirtualBox:~/CentiDev-1.2.0b_KW/app/libusb-1.0.8/libusb/.libs$ ls -la
2
total 580
3
drwxr-xr-x 2 michael michael   4096 2010-12-17 20:52 .
4
drwxr-xr-x 5 michael michael   4096 2010-12-17 20:52 ..
5
-rw-r--r-- 1 michael michael 201174 2010-12-17 20:52 libusb-1.0.a
6
lrwxrwxrwx 1 michael michael     16 2010-12-17 20:52 libusb-1.0.la -> ../libusb-1.0.la
7
-rw-r--r-- 1 michael michael  40436 2010-12-17 20:52 libusb_1_0_la-core.o
8
-rw-r--r-- 1 michael michael  30240 2010-12-17 20:52 libusb_1_0_la-descriptor.o
9
-rw-r--r-- 1 michael michael    955 2010-12-17 20:52 libusb-1.0.lai
10
-rw-r--r-- 1 michael michael  38772 2010-12-17 20:52 libusb_1_0_la-io.o
11
-rw-r--r-- 1 michael michael  82500 2010-12-17 20:52 libusb_1_0_la-linux_usbfs.o
12
-rw-r--r-- 1 michael michael  16184 2010-12-17 20:52 libusb_1_0_la-sync.o
13
lrwxrwxrwx 1 michael michael     19 2010-12-17 20:52 libusb-1.0.so -> libusb-1.0.so.0.0.0
14
lrwxrwxrwx 1 michael michael     19 2010-12-17 20:52 libusb-1.0.so.0 -> libusb-1.0.so.0.0.0
15
-rwxr-xr-x 1 michael michael 156561 2010-12-17 20:52 libusb-1.0.so.0.0.0

lg,
Michael

von Wat (Gast)


Lesenswert?

Du versucht die libusb für den ARM9 mittels eines cross-compilers auf 
einem x86 System zu erzeugen. Das Problem besteht darin, dass das 
x86-libtool versucht nun die erstellte ARM-Bibliothek zu verarbeiten:
/bin/bash ../libtool  --tag=CC   --mode=link arm-920t-linux-gnu-gcc  -g 
-O2   -o lsusb lsusb.o ../libusb/libusb-1.0.la -lusb-1.0 -lrt
libtool: link: arm-920t-linux-gnu-gcc -g -O2 -o .libs/lsusb lsusb.o 
../libusb/.libs/libusb-1.0.so -lrt -pthread
../libusb/.libs/libusb-1.0.so: could not read symbols: Invalid operation

Und mit dieser Bibliothek kann er naturgemäss nichts anfangen... Die 
Bibliothek wird ja scheinbar korrekt erstellt. Hast du ausprobiert ob 
sie funktioniert?

von Michael P (Gast)


Lesenswert?

Das mit libtool habe ich befürchtet.
Ich wollte eben mit dem lsusb Tool herausfinden ob die Bibliothek 
funktioniert.
Ohne libtool kann man lsusb wohl nicht übersezen?

von ichbins (Gast)


Lesenswert?

Für sowas habe ich eine Debian-ARM-Qemu VM und dort compiliere ich dann 
"nativ", bisher jedes Problem damit umgehen können.

von Michael P. (michael_p)


Lesenswert?

Bin mir nicht sicher ob ich das richtig verstanden habe.

Du hast also in einer VM sowas hier laufen 
http://www.aurel32.net/info/debian_arm_qemu.php und das wurde alles mit 
einem ARM Compilier übersetzt (auch libtools ?), und daher kannst du 
dort problemlos alles übersetzen und es dann einfach für dein 
Targetsystem übernehmen?

Wie kann das so generell sein? Ist ja nicht das Selbe ob man für ARM9 
oder ARM11 übersetzen will.

lg,
Michael

von Michael P. (michael_p)


Lesenswert?

ok vergeßt die Frage, ich sehe gerade dass ich sogar beim Übersetzen von 
libusb einen Fehler gemacht habe und dort gcc und nicht der 
cross-compiler verwendet wurde. Dafür habe ich aber bei lsusb den 
cross-compiler verwendet  :-)

von Michael P. (michael_p)


Lesenswert?

Nachdem ich nun in der Lage bin alles richtig zu kompilieren, scheitere 
ich nun an der Lauffähigkeit von libusb auf meinem Centipad.

Das Testprogramm läuft und kann auch brav auf die libusb zugreifen, nur 
wird es immer sofort mit einem Fehler terminiert:

libusb:error [usbfs_scan_busdir] opendir '/dev/bus/usb/001' failed, 
errno=2

Ein Blick auf /dev/bus/usb zeigt mir dass es dort nur ein 1 aber kein 
001 directory gibt (also ohne führende Nullen).
Das scheint ein Problem des alten Kernels (2.6.16.33) der im Centipad 
verwendet wird zu sein. Neuere verwenden hier anscheinend führende 
Nullen.

Nun bin ich zwar froh halbwegs zu verstehen wie man Applikationen und 
shared libraries für das Centipad übersetzt, aber einen neuen Kernel zu 
übersetzen....
Einfach mal die Sourcen ziehen und make kernel wird es wohl nicht sein, 
oder? Hat das schon mal wer gemacht?


lg,
Michael

Hier die Fehleranalyse der libusb Jungs:
1
Michael wrote:
2
> linux kernel 2.6.16.33
3
4
5
This is REEEAALLY old. Get 2.6.*36* instead.
6
7
Commit: 72be3fc830471a1b85069b6c1876f752d036c169
8
Author: Adrian Bunk <bunk@stusta.de> Wed, 22 Nov 2006 19:06:31 +0100
9
   Linux 2.6.16.33
10
11
Over four(!!) years! It is buggy as hell.
12
13
14
15
Michael wrote:
16
> I guess I'm getting closer to the root cause. I've turned on
17
> debugging and I get this error message after
18
> libusb_get_device_list()
19
>
20
> libusb:error [usbfs_scan_busdir] opendir '/dev/bus/usb/001' failed,
21
> errno=2
22
>
23
> Strange thing is that I've got only /dev/bus/usb/1 and not
24
> /dev/bus/usb/001 visible in my system
25
>
26
> Is there any way I can tell libusb to search for 1 instead of 001,
27
28
29
Only by changing the code. I don't know if this is a significant
30
problem for people, but they really should not be using so old
31
kernels. Adding a check also for %d in libusb is easy enough, so
32
maybe worth for us to do, but really..
33
34
35
36
> or is this rather an error of my linux distribution?
37
38
39
..you should just upgrade to a modern kernel and it'll work.
40
41
42
//Peter

von Klaus W. (mfgkw)


Lesenswert?

Evtl. kann man auf die Schnelle mit einem symbolischen Link helfen
(/dev/bus/usb/001 nach /dev/bus/usb/1).

Aber bevor ich den Kernel ändere und damit etwas anderes nicht
mehr geht, würde ich vielleicht in libusb die Stelle suchen, wo
er sich das /dev/bus/usb/001 zusammenschraubt und vielleicht
dort auf /dev/bus/usb/1 ändern?

von Rolf M. (rmagnus)


Lesenswert?

Michael P. schrieb:
> Konfiguration mit "./configure --target=ARM-linux"

--target wird hier nicht das richtige sein und wird bei der libusb 
wahrscheinlich eh keinerlei Auswirkung haben. Du suchst eher --host. Und 
"ARM-linux" ist wahrscheinlich auch nicht passend.

> danach noch im makefile das
> CC = gcc
> gegen
> CC = arm-920t-linux-gnu-gcc
> ersetzen und mit make übersetzen.

Damit compilierst du es eigentlich für den PC, schiebst ihm aber 
hintenrum den ARM-Compiler als PC-Compiler unter. Kein Wunder, daß 
libtool damit nicht klar kommt.

Wenn du's richtig angibst, wird der passende Compiler auch automatisch 
eingetragen, sofern sein Name nicht vom standardmäßig vorgesehenen 
abweicht. Am generierten Makefile muß man eigentlich nie von Hand was 
ändern. Den Compiler explizit setzen kann man auch, indem man vor dem 
configure die Umgebungsvariable CC entsprechend setzt.

Was passiert bei:

./configure --host=arm-920t-linux-gnu

?

von Michael P. (michael_p)


Lesenswert?

Hallo Rolf,

Danke für deine korrekte Darstellung und Lösung des Problems, es hat 
sich allerdings sowieso schon gelöst :-)

Michael P. schrieb:
> Nachdem ich nun in der Lage bin alles richtig zu kompilieren...


./configure --host=arm-920t-linux-gnu ist goldrichtig

von Michael P. (michael_p)


Lesenswert?

ein Update von mir:

Klaus Wachtler schrieb:
> Evtl. kann man auf die Schnelle mit einem symbolischen Link helfen
> (/dev/bus/usb/001 nach /dev/bus/usb/1).

Das hat tatsächlich funktioniert, hat aber das Problem nur verlagert.
Jetzt passiert halt weiter hinten in der libusb ein Fehler.

Die libusb-Entwickler greifen das nicht an weil der Kernel zu alt ist, 
andererseits wäre es auch vermessen auf ein Kernelupdate beim Centipad 
zu hoffen. Mir war das Risiko bewußt als ich mir das Centipad gekauft 
habe, wollte es aber trotzdem ausprobieren.  Cest la vie ;-)

Werde mir wohl ein teures Gumstix-Board holen...

Trotzdem Danke Klaus für deine tolle Unterstützung!

lg,
Michael

Bitte 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
Noch kein Account? Hier anmelden.