Plattformunabhängigkeit
-
Mit dem Switch "-c" sagst Du Deinem gcc "Bitte nicht den Linker laufen lassen, erstell mir nur Objektdateien". Lass den mal weg, das kann Dein Router gar nicht ausführen können.
-
Danke^^
Daran liegt es aber leider nicht.
Ich glaube aber, ich habe den Fehler gefunden, der crosscompiler benutzt ganze lib und der Router die von uClibc.
Werde mal sehen, ob das der Fehler ist.
-
-
Habe den Link getestet, ist aber x86-64 architketur, meiner ist Intel 80... architektur, deshalb läuft es nicht. Trotzdem danke.
Muss es also selbst bauen, crosscompiler läuft, uClibc noch nicht.
libc/sysdeps/linux/common/sendfile.c:20: error: conflicting types for 'sendfile64' ./include/sys/sendfile.h:47: error: previous declaration of 'sendfile64' was here libc/sysdeps/linux/common/sendfile.c:20: error: conflicting types for 'sendfile64' ./include/sys/sendfile.h:47: error: previous declaration of 'sendfile64' was here
sendfile.c:
/* vi: set sw=4 ts=4: */ /* * sendfile() for uClibc * * Copyright (C) 2000-2006 Erik Andersen <andersen@uclibc.org> * * Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball. */ #include <sys/syscall.h> #include <unistd.h> #include <sys/sendfile.h> #ifdef __NR_sendfile _syscall4(ssize_t, sendfile, int, out_fd, int, in_fd, __off_t *, offset, size_t, count) #if ! defined __NR_sendfile64 && defined __UCLIBC_HAS_LFS__ strong_alias(sendfile,sendfile64) #endif #endif /* __NR_sendfile */
sendfile64:
/* * Copyright (C) 2000-2006 Erik Andersen <andersen@uclibc.org> * * Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball. */ /* sendfile64 syscall. Copes with 64 bit and 32 bit machines * and on 32 bit machines this sends things into the kernel as * two 32-bit arguments (high and low 32 bits of length) that * are ordered based on endianess. It turns out endian.h has * just the macro we need to order things, __LONG_LONG_PAIR. */ #include <features.h> #include <unistd.h> #include <errno.h> #include <endian.h> #include <stdint.h> #include <sys/sendfile.h> #include <sys/syscall.h> #include <bits/wordsize.h> #if defined __UCLIBC_HAS_LFS__ && defined __NR_sendfile64 _syscall4(ssize_t,sendfile64, int, out_fd, int, in_fd, __off64_t *, offset, size_t, count) #endif
Wenn ich sendfile ausklammere kommt das:
In file included from /usr/include/asm/posix_types.h:4, from /usr/include/linux/posix_types.h:47, from /usr/include/linux/types.h:5, from /usr/include/linux/if_ether.h:24, from ./include/netinet/if_ether.h:26, from ./include/netinet/ether.h:26, from libc/inet/ethers.c:14: /usr/include/asm/posix_types_64.h:10: error: redefinition of typedef '__kernel_ino_t' ./include/bits/kernel_types.h:38: error: previous declaration of '__kernel_ino_t' was here /usr/include/asm/posix_types_64.h:11: error: redefinition of typedef '__kernel_mode_t' ./include/bits/kernel_types.h:39: error: previous declaration of '__kernel_mode_t' was here /usr/include/asm/posix_types_64.h:12: error: redefinition of typedef '__kernel_nlink_t' ./include/bits/kernel_types.h:48: error: previous declaration of '__kernel_nlink_t' was here /usr/include/asm/posix_types_64.h:13: error: redefinition of typedef '__kernel_off_t' ./include/bits/kernel_types.h:51: error: previous declaration of '__kernel_off_t' was here /usr/include/asm/posix_types_64.h:14: error: redefinition of typedef '__kernel_pid_t' ./include/bits/kernel_types.h:52: error: previous declaration of '__kernel_pid_t' was here /usr/include/asm/posix_types_64.h:15: error: conflicting types for '__kernel_ipc_pid_t' ./include/bits/kernel_types.h:53: error: previous declaration of '__kernel_ipc_pid_t' was here /usr/include/asm/posix_types_64.h:16: error: conflicting types for '__kernel_uid_t' ./include/bits/kernel_types.h:54: error: previous declaration of '__kernel_uid_t' was here /usr/include/asm/posix_types_64.h:17: error: conflicting types for '__kernel_gid_t' ./include/bits/kernel_types.h:55: error: previous declaration of '__kernel_gid_t' was here /usr/include/asm/posix_types_64.h:18: error: conflicting types for '__kernel_size_t' ./include/bits/kernel_types.h:56: error: previous declaration of '__kernel_size_t' was here /usr/include/asm/posix_types_64.h:19: error: conflicting types for '__kernel_ssize_t' ./include/bits/kernel_types.h:57: error: previous declaration of '__kernel_ssize_t' was here /usr/include/asm/posix_types_64.h:20: error: conflicting types for '__kernel_ptrdiff_t' ./include/bits/kernel_types.h:58: error: previous declaration of '__kernel_ptrdiff_t' was here /usr/include/asm/posix_types_64.h:21: error: redefinition of typedef '__kernel_time_t' ./include/bits/kernel_types.h:59: error: previous declaration of '__kernel_time_t' was here /usr/include/asm/posix_types_64.h:22: error: redefinition of typedef '__kernel_suseconds_t' ./include/bits/kernel_types.h:60: error: previous declaration of '__kernel_suseconds_t' was here /usr/include/asm/posix_types_64.h:23: error: redefinition of typedef '__kernel_clock_t' ./include/bits/kernel_types.h:61: error: previous declaration of '__kernel_clock_t' was here /usr/include/asm/posix_types_64.h:26: error: conflicting types for '__kernel_daddr_t' ./include/bits/kernel_types.h:62: error: previous declaration of '__kernel_daddr_t' was here /usr/include/asm/posix_types_64.h:27: error: redefinition of typedef '__kernel_caddr_t' ./include/bits/kernel_types.h:63: error: previous declaration of '__kernel_caddr_t' was here /usr/include/asm/posix_types_64.h:28: error: redefinition of typedef '__kernel_uid16_t' ./include/bits/kernel_types.h:64: error: previous declaration of '__kernel_uid16_t' was here /usr/include/asm/posix_types_64.h:29: error: redefinition of typedef '__kernel_gid16_t' ./include/bits/kernel_types.h:65: error: previous declaration of '__kernel_gid16_t' was here /usr/include/asm/posix_types_64.h:32: error: redefinition of typedef '__kernel_loff_t' ./include/bits/kernel_types.h:71: error: previous declaration of '__kernel_loff_t' was here /usr/include/asm/posix_types_64.h:37: error: conflicting types for '__kernel_fsid_t' ./include/bits/kernel_types.h:77: error: previous declaration of '__kernel_fsid_t' was here /usr/include/asm/posix_types_64.h:39: error: conflicting types for '__kernel_old_uid_t' ./include/bits/kernel_types.h:68: error: previous declaration of '__kernel_old_uid_t' was here /usr/include/asm/posix_types_64.h:40: error: conflicting types for '__kernel_old_gid_t' ./include/bits/kernel_types.h:69: error: previous declaration of '__kernel_old_gid_t' was here /usr/include/asm/posix_types_64.h:41: error: conflicting types for '__kernel_uid32_t' ./include/bits/kernel_types.h:66: error: previous declaration of '__kernel_uid32_t' was here /usr/include/asm/posix_types_64.h:42: error: conflicting types for '__kernel_gid32_t' ./include/bits/kernel_types.h:67: error: previous declaration of '__kernel_gid32_t' was here /usr/include/asm/posix_types_64.h:44: error: conflicting types for '__kernel_old_dev_t' ./include/bits/kernel_types.h:70: error: previous declaration of '__kernel_old_dev_t' was here make: *** [libc/inet/ethers.os] Fehler 1
Habe Linux_Headers auf crosstool umgestellt, dann kommt der Fehler bei uClibc0.9.32rc2:
AR cr lib/libc.a STRIP -x -R .note -R .comment lib/libc.a AR cr lib/uclibc_nonshared.a STRIP -x -R .note -R .comment lib/uclibc_nonshared.a AR cr libc/libc_so.a STRIP -x -R .note -R .comment libc/libc_so.a LD libuClibc-0.9.32-rc2.so libc/libc_so.a(lutimes.os)(.text+0xac): In function `lutimes': : undefined reference to `__GI_utimensat' collect2: ld returned 1 exit status make: *** [lib/libc.so] Fehler 1
Bei uClibc0.9.31 kommt dann:
AR cr lib/libc.a STRIP -x -R .note -R .comment lib/libc.a AR cr lib/uclibc_nonshared.a STRIP -x -R .note -R .comment lib/uclibc_nonshared.a AR cr libc/libc_so.a STRIP -x -R .note -R .comment libc/libc_so.a LD libuClibc-0.9.31.so LD libdl-0.9.31.so /opt/crosstool/gcc-3.4.5-glibc-2.3.6/mipsel-unknown-linux-gnu/lib/gcc/mipsel-unknown-linux-gnu/3.4.5/../../../../mipsel-unknown-linux-gnu/bin/ld:./lib/libc.so: file format not recognized; treating as linker script /opt/crosstool/gcc-3.4.5-glibc-2.3.6/mipsel-unknown-linux-gnu/lib/gcc/mipsel-unknown-linux-gnu/3.4.5/../../../../mipsel-unknown-linux-gnu/bin/ld:./lib/libc.so:6: parse error collect2: ld returned 1 exit status make: *** [lib/libdl.so] Fehler 1
-
Beim Googlen kommen zwei bestimmte Lösungen:
Kann mir jemand sagen, wo die .configure ist, habe in uClibc,/usr/lib/,/opt/crosscompiler.../lib keine gefunden.
http://www.apachefriends.org/f/viewtopic.php?f=8&t=25114&sid=75d9f53f2ec0f02c24d5fc67d0c25ac
Gelinkt habe ich, funktioniert aber nicht.
Hat sonst noch jemand eine Idee, wie man das Problem löst?
-
Ehrlich gesagt tue ich mir sehr schwer dabei, nachzuvollziehen, was Du überhaupt tust.
Du machst ein wenig den Eindruck als würdest Du einfach nur verzweifelt mit den Armen rudern, ohne eine Ahnung davon zu haben, was Du eigentlich machst.
Was genau willst Du überhaupt machen? Wie wäre es wenn Du einfach mal ein bisschen googelst, statt wüst irgendwas auszuprobieren, ohne zu wissen was?
http://wiki.debian.org/BuildingCrossCompilers
http://www.emdebian.org/debian/
-
Danke für die Links, aber ich habe einen laufenden Crosscompiler, dieser funktioniert auch, das einzige Problem ist, das der Crosscompiler die normale libc enthält und diese verwendet.
Der Router stattdessen benutzt die uClibc, eine abgespeckte Bibliothek mit nur den wichtigsten Funktionen.
Ich habe eine jar crosscompiliert und auf den Router ausgeführt, da kam die Meldung, dass er sie nicht findet obwohl sie über ls -la sichtbar ist.
Ich habe von jemanden mal gehört, dass es der Fehler wahrscheinlich da ist, weil die beiden verschiedene Bibliotheken benutzten.
Deshalb bin ich auf uClibc gegangen, habe mir dies gedownloadet, einige Einstellungen gemacht und über make dann die Datei ausgeführt, darauf kommen die folgenden Fehlermeldungen.
--> Dabei fällt mir ein dank deiner Rückfrage ein: Ich habe auch eine javavm auf den Router!
Benutze ich dann diesen Weg:
Habe ich jetzt getestet die jar und er sagt mir, dass er die librxtx.so benötigt, diese habe ich als Quellcode da und auch für meinen PC.
Dann habe ich die Quelldatei versucht über crosscompiler zu linken.
Wobei folgende Fehlermeldung kommt:
a@debian:~/Desktop/rxtx$ make /opt/crosstool/gcc-3.4.5-glibc-2.3.6/mipsel-unknown-linux-gnu/mipsel-unknown-linux-gnu/bin/gcc -fPIC -DPIC -c SerialImp.c In file included from SerialImp.c:25: gnu_io_RXTXPort.h:2:17: jni.h: No such file or directory
Ich nehme dann wohl die alternative Lösung.(Läuft wenn ich nicht den crosscompiler benutzte)
Danke nochmal für die Nachfrage.
Ich werde mich auf jeden Fall noch mal melden, ob ich den Fehler beheben konnte oder nicht.
-
Asgar13 schrieb:
Wobei folgende Fehlermeldung kommt:
[code]
a@debian:~/Desktop/rxtx$ make
/opt/crosstool/gcc-3.4.5-glibc-2.3.6/mipsel-unknown-linux-gnu/mipsel-unknown-linux-gnu/bin/gcc -fPIC -DPIC -c SerialImp.c
In file included from SerialImp.c:25:
gnu_io_RXTXPort.h:2:17: jni.h: No such file or directory
[…]Warum postest Du diesen Riesenhaufen Müll, wenn der Fehler ganz oben steht? In SerialImp.c soll jni.h eingebunden werden, die wird aber nicht gefunden. Die Hunderten Zeilen darunter sind völlig uninteressante Folgefehler.
-
oO Sorry, habe ich übersehen.
Habe jetzt den oberen Beitrag von mir gekürzt.
Es funktioniert!!!
Datei jni.h, jni_mhd.h(Ordner classpath) zum mipsel include-Verzeichnis hinzugefügt.
-> headerdateien sind plattformunabhängig(komisch, das diese Information nirgendwo steht) weil sie (so etwas wie) Quellcode sind.
Danke nman
Bei mir bleibt nur die Frage, warum die uClibc bei mir so viele Fehler ausgibt?
-
Asgar13 schrieb:
Habe jetzt den oberen Beitrag von mir gekürzt.
Danke. Die 900nochwas Zeilen waren doch eine Spur zu derb.
Datei jni.h, jni_mhd.h(Ordner classpath) zum mipsel include-Verzeichnis hinzugefügt.
Ich hoffe, Du hast einfach den Include-Pfad per Compileroptionen hinzugefügt und nicht einfach Dateien herumkopiert.
-> headerdateien sind plattformunabhängig(komisch, das diese Information nirgendwo steht) weil sie (so etwas wie) Quellcode sind.
Headerdateien _sind_ Quellcode.
Aber plattformunabhängig sind sie deswegen nicht zwangsläufig. Du kannst sie natürlich überall lesen, aber wenn sich der Entwickler zB. auf die Größe irgendwelcher Datentypen verlässt und die nicht auf allen Plattformen gleich ist, hast Du plattformabhängigen Sourcecode. Kommt vor.