generelle Fragen zum Crosscompiling und der Toolchain

[IngoF]

Hat jemand generelle Infos zum CrossCompiling oder der Toolchain?

Wenn ich es richtig verstanden habe sind diese Toolchains nur zum CrossCompiling auf einem Linux-PC zu gebrauchen.
Habe auf einem Windows-PC andLinux zum laufen bekommen und die Toolchain heruntergeladen und entpackt.
Leider habe ich nicht die meiste Ahnung von Linux und versuche erst seit fünf Tagen ein Programm für die Diskstation zu kompilieren. Da das kompilieren auf der DIskstation wegen zu altem GCC nicht geht bleibt nur CrossCompiling. Hier mein Versuch.

Hier habe ich in der Fußnote erfahren dass es Probleme gibt zwei ausführbare Programme mit selben Namen im Pfad PATH zu finden.
Warum heisst der gcc in der toolchain auch gcc?

Ich habe jetzt andLinux auf dem PC installiert, die toolchain heruntergeladen und entpackt. Den leeren Ordner /usr/local/bin habe ich gelöscht und einen symbolischen Link auf den bin-Ordner der Toolchain erstellt.
der gcc ist also durch /usr/local/bin/gcc zu starten. Dieser Pfad steht als erstes im PATH. trotzdem wird immer mit gcc gcc des andLinux gestartet. Nach Deinstallation mit apt-get remove gcc wird jetzt kein gcc mehr gefunden. Die Installation des gcc ist allerdings auch nicht mehr möglich.

Habe versucht dieser Anleitung zu folgen. Ich möchte aber ein anderes Programm compilieren.

Wie man sieht habe ich es noch niemals geschafft ein Hallo-Welt zu kompilieren.

Hoffe mir ist noch zu helfen

Bin für jeden Hinweis Dankbar....

 

[Ameisentaetowierer]

Hi,

ich kann dir nicht ganz folgen.
Zunächst schreibst du, dass das Kompilieren auf deiner Syno nicht geht, wg. zu altem Compiler.
Dann schreibst du von deinem Versuch, wo per ipkg der gcc auf einer Syno installiert wird.
Das ist für mich "natives" Kompilieren, da du auf der Zielplattform kompilierst.

Danach kommt der Sprung zum cross-compiling, wo dir auffällt, dass der gcc immer gcc heißt.
Der gcc zum cross-compiling heißt aber -in dem Beispiel- "arm-linux-gcc" (steht auch so in https://www.ailis.de/~k/archives/19-ARM-cross-compiling-howto.html#libraries)

Ich empfehle das Studium von https://global.download.synology.com/download/Document/DeveloperGuide/DSM_Developer_Guide.pdf

Cross-compiling ist keine einfache Sache, deshalb versuchen die meisten Leute auch, direkt auf ihrer Syno zu kompilieren.
Beim cross-compiling ist es sehr wichtig, dass man versteht, wann der Comiler bzw. Linker auf was zugreift.
Dazu reicht es nicht, wenn man die nativen Tools deinstalliert, damit nur noch die cross-compile Tools gefunden werden.
Man muss sich eine Entwicklungsumgebung (Environment) einrichten, damit der gewünschte Compiler und Linker aufgerufen werden und ggf. auch die gewünschten Libraries und Includes gefunden werden.
Das Linken von gcc, ld, etc. nach /usr/local/bin ist m.E. eine dumme Idee, da hätte der Autor auch einfach mal seine PATH-Variable anpassen können.

Wenn's nicht auf Anhieb klappt, mach dir keine Sorgen, diese Thema ist kein Leichtes, schon gar nicht, wenn man sich nicht mit Linux auskennt.

 

[IngoF]

Hi,
Ich empfehle das Studium von https://global.download.synology.com/download/Document/DeveloperGuide/DSM_Developer_Guide.pdf

Danke für den Link. Bin dann gestern doch mal dazu gekommen mir diese Anleitung anzusehen. Dachte immer es geht nur darum SPK-Pakete zu bauen wenn schon compilierte Programme vorhanden sind.
Aber dort ist ja auch eine Anleitung zum CrossCompilieren und der Toolchain.

Habe gestern auch noch mal angefangen das mit andLinux zu testen. Aber irgendwie klappt das nicht so wirklich. Vielleicht liegt es auch an meinem zu alten Laptop.
Sorry für die Verwirrungen. Hätte den Link zu meinem nativen kompilieren wohl nicht verlinken sollen. Dort hing es dann hinterher am gcc Compiler der einfach zu alt ist. Ich benötige schon gcc 4.6 oder besser noch 4.7.

Lade mir gerade unbuntu herunter und versuche das mal parallel zu meinem Windows auf meinem richitgen PC zu installieren.

 

[IngoF]

Durch den Development-Guide scheine ich mein Ziel so gut wie erreicht zu haben.

Nur der erste Boost-Import funktioniert nicht. Es kommt "Datei oder Verzeichnis nicht gefunden".

#include <boost/scoped_ptr.hpp>

ich habe natürlich in Ubuntu mit apt-get install libboost-all-dev die Boost-Bibliothek installiert.
Hat jemand eine Ahnung in welchem Pfad die liegen sollten?

Habe zwar einen Ordner von Boost gefunden. Aber das sind keine *.SO oder *.HPP Dateien zu finden.

Was muss denn sonst installiert werden? Wie kann ich überprüfen wo die scoped_ptr.hpp ist. find /usr/ scoped_ptr.hpp konnte nichts finden.

 

[Ameisentaetowierer]

Ich glaube, du hast da einen Denkfehler.
Du brauchst eine Verzeichnisstruktur auf deiner Festplatte, die der Verzeichnisstruktur auf der Syno entspricht.
Damit ist dann z.B. /usr auf der Syno, nicht gleich /usr auf dem Linux, sondern z.B. /unterverzeichnis/usr
Wo und wie du das mit dem Unterverzeichnis machst, bleibt deine Sache.
Aber du brauchst die Entwicklungsumgebung der Syno in dem Verzeichnisbaum von /unterverzeichnis/*

Wenn du jetzt für dein Projekt eine Lib oder ein Include brauchst, das nicht von der Syno kommt, dann musst du das ebenfalls erstmal cross-kompillieren und nach /unterverzeichnis/usr/local installieren.
Denn dann musst du auch das erstmal selbst wieder auf der Syno installieren....

Lass die Finger von /unterverzeichnis/usr/bin oder /unterverzeichnis/etc!
Deine Zielstruktur liegt immer unter /unterverzeichnis/usr/local, bzw. später dann /usr/local auf der Syno.
Dieses Unterverzeichnis ist für Erweiterungen, die nicht vom Hersteller sind, da darfst du dich austoben.
Wie du das dann von deinem PC zur Syno bekommst, ist das nächste Problem....

Probier' erstmal "Hello World", dann ist schonmal ein Erfolgserlebnis da ;-)

 

[dil88]

Sollte das Compilieren einer Lib besonders schwierig sein, kann man sie zur Not auch statisch linken. Aber das bläht natürlich die Größe des binaries auf.

 

[IngoF]

DANKE für die Antworten.

Ich glaube, du hast da einen Denkfehler.

Vermutlich ist genau das mein Problem (gewesen).

Probier' erstmal "Hello World", dann ist schonmal ein Erfolgserlebnis da ;-)

Hatte schon mal die Hallo-Welt kompiliert und das Beispiel aus dem Development Guide. Das und das kompilieren der ersten Bibliothek ließ schon mal das Licht am Ende des Tunnels durchscheinen.

Sollte das Compilieren einer Lib besonders schwierig sein, kann man sie zur Not auch statisch linken. Aber das bläht natürlich die Größe des binaries auf.

Die Lib scheint auch schon geklappt zu haben.

Vermutlich wird das letzte Problem nur mit dem Pfad zu tun haben. Werde mir das morgen hoffentlich noch mal ansehen können.

 

[Ameisentaetowierer]

Dann bist du ja schon ziemlich weit.
Ggf. brauchst du zum Auffinden der shared libraries die ENV-Variable LD_LIBRARY_PATH.

Ich habe hier mal ein Beispiel, wie man prüfen kann, welche shared libraries ein Binary (hier ffmpeg) benutzt und ob sie gefunden werden.
Unter Linux benutzt man normalerweise "ldd <programm>", aber da es kein ldd auf der Syno gibt, kann man diesen Workaround benutzen.
Im Beispiel siehst du auch gleich, wie umfangreich die Auswirkunden sein können....

ds> LD_TRACE_LOADED_OBJECTS=1 /usr/local/bin/ffmpeg
libavdevice.so.55 => /lib/libavdevice.so.55 (0x400fc000)
libavfilter.so.4 => not found
libavformat.so.55 => /lib/libavformat.so.55 (0x4010d000)
libavcodec.so.55 => /lib/libavcodec.so.55 (0x40243000)
libpostproc.so.52 => /lib/libpostproc.so.52 (0x4005a000)
libswresample.so.0 => /lib/libswresample.so.0 (0x400c8000)
libswscale.so.2 => /lib/libswscale.so.2 (0x40dee000)
libavutil.so.52 => /lib/libavutil.so.52 (0x40e3c000)
libm.so.6 => /lib/libm.so.6 (0x40e88000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40006000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40f02000)
libc.so.6 => /lib/libc.so.6 (0x40f2a000)
libz.so.1 => /lib/libz.so.1 (0x41067000)
libopencore-amrwb.so.0 => /lib/libopencore-amrwb.so.0 (0x4108a000)
libopencore-amrnb.so.0 => /lib/libopencore-amrnb.so.0 (0x410b9000)
libmp3lame.so.0 => /lib/libmp3lame.so.0 (0x4110a000)
libfaac.so.0 => /lib/libfaac.so.0 (0x41186000)
/lib/ld-linux.so.3 (0x40097000)
libstdc++.so.6 => /lib/libstdc++.so.6 (0x411a5000)
ds>
ds> export LD_LIBRARY_PATH=/usr/local/bin
ds>
ds> LD_TRACE_LOADED_OBJECTS=1 /usr/local/bin/ffmpeg
libavdevice.so.55 => /usr/local/lib/libavdevice.so.55 (0x4014b000)
libavfilter.so.4 => /usr/local/lib/libavfilter.so.4 (0x40164000)
libavformat.so.55 => /usr/local/lib/libavformat.so.55 (0x40213000)
libavcodec.so.55 => /usr/local/lib/libavcodec.so.55 (0x4031c000)
libpostproc.so.52 => /usr/local/lib/libpostproc.so.52 (0x40111000)
libswresample.so.0 => /usr/local/lib/libswresample.so.0 (0x400ed000)
libswscale.so.2 => /usr/local/lib/libswscale.so.2 (0x40f98000)
libavutil.so.52 => /usr/local/lib/libavutil.so.52 (0x40fe1000)
libm.so.6 => /lib/libm.so.6 (0x40018000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4012e000)
libpthread.so.0 => /lib/libpthread.so.0 (0x41036000)
libc.so.6 => /lib/libc.so.6 (0x4105e000)
librt.so.1 => /lib/librt.so.1 (0x400d5000)
/lib/ld-linux.so.3 (0x400a4000)
ds>
ds> export LD_LIBRARY_PATH="/lib:/usr/local/lib"
ds>
ds> LD_TRACE_LOADED_OBJECTS=1 /usr/local/bin/ffmpeg
libavdevice.so.55 => /lib/libavdevice.so.55 (0x40131000)
libavfilter.so.4 => /usr/local/lib/libavfilter.so.4 (0x40142000)
libavformat.so.55 => /lib/libavformat.so.55 (0x401f1000)
libavcodec.so.55 => /lib/libavcodec.so.55 (0x40327000)
libpostproc.so.52 => /lib/libpostproc.so.52 (0x40072000)
libswresample.so.0 => /lib/libswresample.so.0 (0x40030000)
libswscale.so.2 => /lib/libswscale.so.2 (0x40ed2000)
libavutil.so.52 => /lib/libavutil.so.52 (0x400e4000)
libm.so.6 => /lib/libm.so.6 (0x40f20000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40092000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40f9a000)
libc.so.6 => /lib/libc.so.6 (0x40fc2000)
libz.so.1 => /lib/libz.so.1 (0x410ff000)
libopencore-amrwb.so.0 => /lib/libopencore-amrwb.so.0 (0x41122000)
libopencore-amrnb.so.0 => /lib/libopencore-amrnb.so.0 (0x41151000)
libmp3lame.so.0 => /lib/libmp3lame.so.0 (0x411a2000)
libfaac.so.0 => /lib/libfaac.so.0 (0x4121e000)
/lib/ld-linux.so.3 (0x400b3000)
libstdc++.so.6 => /lib/libstdc++.so.6 (0x4123d000)
ds>