USBAT-02 vs. glibc-devel-2.3.2-87
Ich habe valiant:/usr/src/linux # uname -a Linux valiant 2.4.21-192-default #1 Wed Feb 18 19:26:28 UTC 2004 i686 athlon i386 GNU/Linux valiant:/usr/src/linux # cat ./include/linux/version.h #define UTS_RELEASE "2.4.21-192-default" #define LINUX_VERSION_CODE 132117 #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c)) und man sollte meinen, alles ist gut. Ist es aber nicht. Denn wenn ich versuche, den Treiber für mein USBAT-02 neu zu bauen, kommt kris@valiant:~/Download/usbat-02.20031116/src> make clean rm -f *.o kris@valiant:~/Download/usbat-02.20031116/src> make complete cp /usr/src/linux/drivers/usb/storage/debug.c . cp /usr/src/linux/drivers/usb/storage/debug.h . cp /usr/src/linux/drivers/usb/storage/initializers.c . cp /usr/src/linux/drivers/usb/storage/initializers.h . cp /usr/src/linux/drivers/usb/storage/protocol.c . cp /usr/src/linux/drivers/usb/storage/protocol.h . cp /usr/src/linux/drivers/usb/storage/scsiglue.c . cp /usr/src/linux/drivers/usb/storage/scsiglue.h . cp /usr/src/linux/drivers/usb/storage/transport.c . cp /usr/src/linux/drivers/usb/storage/transport.h . cp /usr/src/linux/drivers/usb/storage/unusual_devs.h . cp /usr/src/linux/drivers/usb/storage/usb.c . cp /usr/src/linux/drivers/usb/storage/usb.h . # modify transport.h, unusual_devs.h and usb.c ./modify.pl ctags *.[ch] kris@valiant:~/Download/usbat-02.20031116/src> make cc -D__KERNEL__ -DMODULE -I. -I/usr/src/linux/drivers/usb/storage -I/usr/src/linux/include -I../scsi -O -Wall -march=i386 -DCONFIG_USB_STORAGE_USBAT2 -c -o scsiglue.o scsiglue.c In file included from /usr/src/linux/include/linux/usb.h:136, from usb.h:47, from scsiglue.c:48: /usr/include/linux/version.h:2:2: #error "=======================================================" /usr/include/linux/version.h:3:2: #error "You should not include /usr/include/{linux,asm}/ header" /usr/include/linux/version.h:4:2: #error "files directly for the compilation of kernel modules." /usr/include/linux/version.h:5:2: #error "" ... Sieht man sich dann /usr/include/linux/version.h näher an, bekommt man kris@valiant:~/Download/usbat-02.20031116/src> cat /usr/include/linux/version.h ... #else #define UTS_RELEASE "2.6.0-test3" #define LINUX_VERSION_CODE 132608 #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c)) #endif Wieso liegen auf diesem System 2.6er Headers rum? Und zu welchem Paket gehören die überhaupt? kris@valiant:~/Download/usbat-02.20031116/src> rpm -qf /usr/include/linux/version.h glibc-devel-2.3.2-87 Kann mir jemand erklären, was das soll? Und wie ich mein Bus 001 Device 003: ID 04e6:1010 SCM Microsystems, Inc. USBAT-2 CompactFlash Card Reader ans Rennen kriege? Kristian -- http://www.amazon.de/exec/obidos/wishlist/18E5SVQ5HJZXG
Kristian Köhntopp <kris@koehntopp.de> [So, 29 Feb 2004 21:13:25 +0100]:
/usr/include/linux/version.h:2:2: #error
Hier zieht er den falschen Header rein, den aus /usr/include/linux. Das ist der zur glibc gehörende und damit knallt es, wie du siehst.
Sieht man sich dann /usr/include/linux/version.h näher an, bekommt man
kris@valiant:~/Download/usbat-02.20031116/src> cat /usr/include/linux/version.h
Was dann vollkommen irrelevant ist :)
kris@valiant:~/Download/usbat-02.20031116/src> rpm -qf /usr/include/linux/version.h glibc-devel-2.3.2-87
Kann mir jemand erklären, was das soll?
Die glibc bringt eine eigene Version der Kernelheader mit sich. Dies sind die Header, gegen die sie gebaut wurde. Für Userspace-Applikationen sollte das in der Regel vollkommen reichen. Für echten Kernelcode sind die Header natürlich Gift. Daher sollte man ja auch -I/usr/src/linux/include oder noch besser -I/lib/modules/<kernel_version>/build/include verwenden. Du solltest mal nachprüfen, warum das scsiglue.c den falschen Header reinzieht.
Und wie ich mein
Bus 001 Device 003: ID 04e6:1010 SCM Microsystems, Inc. USBAT-2 CompactFlash Card Reader
ans Rennen kriege?
Durch Lösung des obigen Problems? Im Zweifelsfall schick mir mal die URL zu dem Quellcode und ich werfe einen Blick darauf. Philipp
On Sun, Feb 29, Kristian Köhntopp wrote:
Sieht man sich dann /usr/include/linux/version.h näher an, bekommt man
kris@valiant:~/Download/usbat-02.20031116/src> cat /usr/include/linux/version.h ... #else #define UTS_RELEASE "2.6.0-test3" #define LINUX_VERSION_CODE 132608 #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c)) #endif
Wieso liegen auf diesem System 2.6er Headers rum? Und zu welchem Paket gehören die überhaupt?
Warum liest Du nicht den langen Kommentar am Anfang dieser Datei, sondern nur das Ende? Da steht, was Du falsch machst. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE Linux AG Maxfeldstr. 5 D-90409 Nuernberg -------------------------------------------------------------------- Key fingerprint = A368 676B 5E1B 3E46 CFCE 2D97 F8FD 4E23 56C6 FB4B
On Monday 01 March 2004 08:58, Thorsten Kukuk wrote:
Warum liest Du nicht den langen Kommentar am Anfang dieser Datei, sondern nur das Ende? Da steht, was Du falsch machst.
Weil ich genervt bin. Ich muß ca. alles halbe Jahr die Card von der Kamera leer machen (die ist ziemlich groß), und jedes einzelne Mal muß ich den verblödeten Treiber neu übersetzen und jedes einzelne Mal geht was anderes schief. Und eigentlich will ich nur die Bilder haben und mich nicht durch Kernel Includes wühlen. Ist aber egal, ich hab dann Windows 98 in der vmware gebootet. Damit ging es auf Anhieb und ohne mit dem System diskutieren zu müssen, welche Version von was jetzt installiert ist. Kristian
Kristian Köhntopp wrote:
[...] Weil ich genervt bin. Ich muß ca. alles halbe Jahr die Card von der Kamera leer machen (die ist ziemlich groß), und jedes einzelne Mal muß ich den verblödeten Treiber neu übersetzen und jedes einzelne Mal geht was anderes schief.
Das verstehe ich nicht. Wieso musst Du jedesmal den Treiber neu installieren/uebersetzen? Das kann ja eigentlich nur sein, wenn Du ein Kernel Update/Upgrade gemacht hast und somit das "alte" Modul nicht mehr zum "neuen" Kernel passt. Dann ist es aber unter Windows (den Vergleich hast Du ja herangezogen) nicht anders - wenn Du auf ein neues Betriebssystem umsteigst, musst Du sicher auch die Software bzw. den Treiber neu installieren. Gruesse, Th.
On Monday 01 March 2004 21:21, Thomas Hertweck wrote:
Das verstehe ich nicht. Wieso musst Du jedesmal den Treiber neu installieren/uebersetzen?
Weil in der Zwischenzeit mal wieder irgendein Kernelupgrade einen Reboot und einen Neubau der usbat- und der vmware-Module erzwungen hat.
Dann ist es aber unter Windows (den Vergleich hast Du ja herangezogen) nicht anders - wenn Du auf ein neues Betriebssystem umsteigst, musst Du sicher auch die Software bzw. den Treiber neu installieren.
Nach dem Einspielen von Windows Patches muß ich in der Regel nicht neue Versionen sämtlicher Treiber besorgen. Kristian
Kristian Köhntopp wrote:
On Monday 01 March 2004 21:21, Thomas Hertweck wrote:
Das verstehe ich nicht. Wieso musst Du jedesmal den Treiber neu installieren/uebersetzen?
Weil in der Zwischenzeit mal wieder irgendein Kernelupgrade einen Reboot und einen Neubau der usbat- und der vmware-Module erzwungen hat.
Erklaere mir mal, wie Du ohne Reboot einen neuen Kernel zum Laufen bringen willst!? Erklaere mir mal, wie ein Kernel-Modul ohne Recompilieren weiter funktionieren soll, wenn sich z.B. das Kernel-Interface o.ae. geaendert hat?! Wenn sich keine entscheidenden Dinge geaendert haben, kannst Du das Kernel-Modul auch weiterhin verwenden nach einem Kernel-Patch. Wenn natuerlich ein komplett neuer Kernel eingespielt wird, naja, was dann passiert, brauche ich Dir ja wohl nicht zu erklaeren...
[...] Nach dem Einspielen von Windows Patches muß ich in der Regel nicht neue Versionen sämtlicher Treiber besorgen.
Wenn Du einen neuen Windows-Kernel installierst und sich essentielle Dinge aendern, auf die der Treiber Zugriff nimmt, wirst Du das sicher auch muessen. CU, Th.
participants (4)
-
Kristian Köhntopp -
Philipp Thomas -
Thomas Hertweck -
Thorsten Kukuk