4. Plattformunabhängigkeit

Plattformunabhängigkeit

  • A

    nman schrieb:

    Asgar13 schrieb:

    Aber zu Punkt 2 habe ich noch eine Frage: Kannst du mir ein C-compiler nennen, der auf einen Router geht, der Crosscompiler funktioniert nicht so recht.

    Versuche lieber, den Crosscompiler richtig bedienen zu lernen, auf Routern Build-Chains zu installieren macht keinen Spaß.

    😕 Ich habe es hinbekommen 😕

    Vor einiger Zeit hatte ich den Crosscompiler mal versucht zu installieren, da kamen sonst was für Fehlermeldungen, habe ihn deshalb runtergeschmissen.

    Nun habe ich die gleiche Version gedownloadet und er hat richtig installiert. 😕

    Habe nun ein Testprogramm mit.

    /opt/crosstool/gcc-3.4.5-glibc-2.3.6/mipsel-unknown-linux-gnu/mipsel-unknown-linux-gnu/bin/gcc -c test -o testit

    kompiliert und über scp auf den Router gepackt und der sagt mir:

    root@DD-WRT:/mnt# ls -la
drwxrwxrwx    5 root     root         4096 Jan  1 04:40 .
drwxr-xr-x   16 root     root          162 Aug  7  2010 ..
drwx------    3 30004    10000        4096 Jan 10  2011 .Trash-30004
-rw-r--r--    1 root     root       623912 Jan  1 03:17 xxx.jar
drwxr-xr-x   46 30004    10000        4096 Jan 14  2011 xxx
drwx------    2 root     root        16384 Nov 15  2010 lost+found
-rwxr-xr-x    1 root     root         6776 Jan  1 04:30 test
-rwxr-xr-x    1 root     root        71768 Jan  1 04:40 testit
root@DD-WRT:/mnt# ./testit
-sh: ./testit: not found

    Kannst du mir sagen, wo der Fehler ist?

    0
  • N

    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.

    0
  • A

    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.

    0
  • N

    http://www.dd-wrt.com/phpBB2/viewtopic.php?t=3668

    0
  • A

    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
    0
  • A

    Beim Googlen kommen zwei bestimmte Lösungen:

    http://bogdan.org.ua/2007/08/10/geany-source-installation-error-libcso-file-format-not-recognized-treating-as-linker-script.html

    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?

    0
  • N

    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/

    0
  • A

    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.

    0
  • N

    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.

    0
  • A

    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?

    0
  • N

    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.

    0
Anmelden zum Antworten