[SOLVED] - TFStubserver - Start unter Arch Linux schlägt fehl

[daywalker]

Hallo,

 

da ich oft unterwegs bin und nicht immer die TF-Hardware mitschleppen möchte, hab ich mir den Emulator TFStubserver mal angeschaut und versucht diesen zu installieren. Leider mit mäßigem Erfolg. Ich kann die kompilierte Datei nicht ausführen.

 

Hier meine Schritte, welche ich getan habe:

 

git clone https://github.com/PlayWithIt/TFStubserver.git
cd TFStubserver
make

 

Anschließend habe ich versucht via "src/stubserver/stub" den Server zu starten. Hier bekomme ich folgende Fehlermeldung:

 

[andreas@arch stubserver]$ ./stub 
./stub: Zeile 35: ../../bin/Debug/stubserver: Keine Berechtigung
[andreas@arch stubserver]$ ./stub -vg
valgrind: ../../bin/Debug/stubserver: Permission denied

 

Der Datei "bin/Debug/stubserver" habe ich auch noch das Executable-Flag gegeben, was zu folgender Fehlermeldung führt:

 

[andreas@arch stubserver]$ ./stub 
./stub: Zeile 35: ../../bin/Debug/stubserver: Kann die Binärdatei nicht ausführen: Fehler im Format der Programmdatei
[andreas@arch stubserver]$ ./stub -vg
valgrind: this is not an executable
valgrind: ../../bin/Debug/stubserver: cannot execute binary file

 

Ein "file" auf die Datei "bin/Debug/stubserver" zeigt folgendes:

 

[andreas@arch stubserver]$ file ../../bin/Debug/stubserver 
../../bin/Debug/stubserver: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

 

Kann mir jemand helfen? Ich komme leider nicht mehr weiter.

 

 

Gruß Andreas

[remotecontrol]

Hallo Andreas,

 

jetzt bin ich etwas irritiert ... hast Du ggf. einen Cross-Compiler auf dem System installiert? Normalerweise sollte der Compiler ja Code für die aktuelle Umgebung erzeugen, es sei denn, Du hast einen Cross-Compiler drauf.

 

Was sagen die Befehle der Art

uname -a
g++ -v
file /bin/bash

falls die bash bei Dir wo anders stehen sollte, den "file" Befehl für ein anderes Binary aus /bin oder /usr/bin ausführen.

 

Viele Grüße

[remotecontrol]

Zurück .. brauchst nichts zu machen, sieht so aus, als sei das falsche Makefile da drin (ich habe ein eigenes für die GIT-Version).

[daywalker]

Hi,

 

hier die Ausgabe der Befehle:

 

[andreas@arch ~]$ uname -a
Linux arch 4.2.2-1-ARCH #1 SMP PREEMPT Tue Sep 29 22:21:33 CEST 2015 x86_64 GNU/Linux

 

andreas@arch ~]$ g++ -v
Es werden eingebaute Spezifikationen verwendet.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/lto-wrapper
Ziel: x86_64-unknown-linux-gnu
Konfiguriert mit: /build/gcc/src/gcc-5.2.0/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib --disable-werror --enable-checking=release --with-default-libstdcxx-abi=gcc4-compatible
Thread-Modell: posix
gcc-Version 5.2.0 (GCC)

 

[andreas@arch ~]$ file /bin/bash
/bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=f72318b432b3b3677cc99f5df5461232c199d569, stripped

[daywalker]

Ah ok...

 

Kannst du mir bitte dieses Makefile zur Verfügung stellen, bzw. würde das Austauschen des Makefiles das Problem beheben?

 

 

Gruß Andreas

[remotecontrol]

Das ist schon peinlich:

Git ist bei mir nur ein Ableger meines Repos wo viel mehr Sourcen sind, darum habe ich ein "abgespecktes" Makefile im Git und zugegeben immer nur den Compile getestet (Unittests habe ich im anderen Baum) und der hatte beim Linken die Option "-c" ...

 

Ich habe das Makefile aktualisiert, synchronisiere bitte nochmal Deinen lokalen Stand und baue es nach (make new).

[remotecontrol]

Der Re-Compile sollte das Problem beheben, gibt mir bitte eine kurze Info, ob es geklappt hat.

 

Wenn alles ok ist, sollte der brickv beim Start mit dem Beispiel 11 Bricklets an 3 Mastern anzeigen (wichtig: auf Port 4225 nicht 4223 wenn keine Optionen verwendet werden).

[daywalker]

Hallo,

 

sehr gut. Der Build-Vorgang war erfolgreich und das Programm startet.

 

[andreas@arch stubserver]$ ./stub 
./stub: Zeile 34: cd: src/stubserver: Datei oder Verzeichnis nicht gefunden
2015-10-12 17:16:00.073698  Bind a socket on port 4225
2015-10-12 17:16:00.073897  BrickThread is running ...

 

Der Connect via BRICK-Viewer klappt auch ohne Probleme.

 

Vielen Dank für die schnelle Hilfe.

 

 

Gruß Andreas

[remotecontrol]

Das Start-Skript habe ich eben auch noch angepasst, dann ist das hier auch weg:

./stub: Zeile 34: cd: src/stubserver: Datei oder Verzeichnis nicht gefunden