Hallo,
ich habe mit openwrt keine Erfahrung, mit Kernel-Konfiguration etwas,
aber nur zu Kernel-2.4 Zeiten.
Ich habe es mal installiert und für den Raspberry PI eine toolchain
generiert mit den Standard-Einstellung bei "make menuconfig".
Dann wollte ich mal ein paar Waves ausgeben.
die Devices sind in /proc/asound/cards vorhanden (intern/usb-extern)
die libraries auch, z.B.
snd-mixer-oss.ko
snd-pcm-dmaengine.ko
snd-pcm-oss.ko
snd-pcm.ko
snd-rawmidi.ko
snd-seq-device.ko
snd-seq-midi-event.ko
snd-seq-midi.ko
snd-seq.ko
snd-timer.ko
snd-usb-audio.ko
snd-usbmidi-lib.ko
snd.ko
Aber es fehlen die header-Dateien zum cross-compilieren eines test
c-programms.
in der toolchain gibt es die sound/*.h header dateien,
da sind strukturen z.B. snd_pcm_access_t definiert, aber es fehlen die
Deklaration von Funtionen zum Starten eines pcm-streams
Wahrscheinlich muss man in der openwrt-Konfiguration etwas auswählen
(z.B. alsa-lib-dev), dass er die Headers entsprechend erstellt ???
Audio schrieb:> die libraries auch, z.B.Audio schrieb:> Aber es fehlen die header-Dateien zum cross-compilieren eines test> c-programms.
Das (*.ko) sind doch Kernel-Module. Damit hast du in normalen
C-Programmen nichts mit zu tun. Du brauchst den Userspace-Teil...
> Du brauchst den Userspace-Teil...
das ist klar.
Aber ich denke, wenn der build-prozess die Kernel-Module rauswirft, dann
müssten die Userspace-Develop Dateien auch dabei sein, wenn man das
entsprechende in der menuconfig anklickt.
Soweit ich weiß gibt es im Kernel überhaupt keine Header oder Libraries
für den Userspace. Die sind beide in separaten Paketen.
libasound2 und libasound2-dev sehen so aus als würden sie Libraries bzw.
Header für ALSA enthalten. Vielleicht wäre es aber sinnvoller direkt
gstreamer o.ä. zu verwenden, dann bist du unabhängig von ALSA und es
gibt noch eine Menge Dateiformate und Codecs dazu...
Niklas G. schrieb:> Soweit ich weiß gibt es im Kernel überhaupt keine Header oder Libraries> für den Userspace. Die sind beide in separaten Paketen.
Header natürlich nicht.
Libraries denke ich schon.
Man kann bei menuconfig des build-prozesses anklicken, ob man jeweilige
Module/Treiber als Module ('m') oder fest im Kernel ('*') haben möchte.
Theoretisch könnte man alles benötigte fest im Kernel haben
(monolithischer Kernel)
Audio schrieb:> Libraries denke ich schon.> Man kann bei menuconfig des build-prozesses anklicken, ob man jeweilige> Module/Treiber als Module ('m') oder fest im Kernel ('*') haben möchte.
Da kommen aber keine Userspace-Libraries (*.a, *.so, *.la, *.o) heraus,
sondern Kernel-Module (*.ko) welche man im Userspace überhaupt nicht
nutzen kann ('m' = 'Module').
Da fehlen mir doch etwas die basics ...
Aber wo krieg ich die alsa-lib-dev headers und sourcen her ?
Wenn ich im kompletten openwrt-Baum ("git clone
https://www.github.com/openwrt/openwrt"; mit allen feeds) suche (grep),
dann finde ich die typischen Alsa-Dateien wie aplay.c gar nicht.
Soll man diese Sourcen dann extern besorgen?
Es scheint ein bisschen anders zu funktionieren als bei normalen Alsa.
Ich habe testweise ein Midi-Keyboard an den RPi mit openwrt
angeschlossen.
dann erscheint die Datei '/dev/snd/midiC1D0'
wenn ich 'cat /dev/snd/midiC1D0' eingebe und Tasten betätige, erscheinen
die Midi-Daten.
Aber ich interessiere mich eigentlich für Sound (PCM) Ein- und Ausgabe
Audio schrieb:> Aber wo krieg ich die alsa-lib-dev headers und sourcen her ?
Im Zweifelsfall bei ALSA direkt:
ftp://ftp.alsa-project.org/pub/lib/
Für Debian gibt es das als libasound2-Paket, vielleicht ja auch für
openwrt?
Es bleibt schwierig.
(Wenn ich mit opkg alsa-lib und alsa-utils installiere, habe ich eine
lib-Datei (asound.so.2) und aplay funktioniert.)
Aber ich kann kein eigenes Programm installieren, wegen nicht
aufgelöster Symbole.
Ich denke das ist mehr ein Fall für Compiler, gcc, und
libc/Alternativen.
Openwrt hat alles optimiert und binaries so klein wie möglich gemacht.
Ich vermute, dass die Symboltabelle irgendwo in einer anderen Datei
vorhanden ist, die man nur für Build-Zwecke braucht, aber nicht zur
execution-Time.
Ich habe versuchsweise die Sourcen direkt von den Alsa-sourcen
(alsa-lib-1.1.6.tar.bz2) cross-kompiliert (gleiche Version wie openwrt
verwendet).
Da bekomme ich ein binary, das 3x mal so groß ist, als das vom
Openwrt-Buildroot.
Die Symbol-Auflösung funktioniert, aber die Ausführung nicht.
Nein du must im Makefile (für das openwrt package)
1
DEPENDS:=+alsa-lib
(oder so ähnlich kann sein das es der ganze odner name des packages ist)
Dann das ganze mit dem SDK compilern.
Die developing files header etc werden in den buildroot des SDKs kopiert
sofern dies im Abschnitt:
1
define Build/InstallDev
2
...
3
endef
angegeben ist
Es gibt dazu eine wikieintrag wie man eigene Packete baut und man kann
sich ganz gut an bestehenden paketen orientieren.
Es funktionieren schon viel einfachere Sachen nicht, und ich verstehe es
nicht.
Nämlich das Kompilieren von einfachen Demo-Progrämchem mit Bibliotheken,
z.B ncurses, scheitert.
Und zwar gibt es im Bin-Verzeichnis ein script, was die benötgiten
GCC-Flags exportiert
hello.c:(.text.startup+0xc): undefined reference to `initscr'
3
hello.c:(.text.startup+0x18): undefined reference to `printw'
4
hello.c:(.text.startup+0x1c): undefined reference to `stdscr'
5
...
(ncurses und ncurses-dev sind natürlich installiert)
Diese nicht aufgelösten Symbole sind mit Sicherheit in der
/usr/lib/libncurses.so drin, aber sie werden nicht erkannt.
Irgenwie scheint mir noch eine Einstellung für den Gcc, zu fehlen.
[pre]
lrwxrwxrwx 1 root root 30 Nov 9 14:00 /usr/bin/gcc ->
aarch64-openwrt-linux-musl-gcc
[pre]
OK ich sehe du compilerst auf der Zielmaschine (Raspberry Pi)
Das ist sehr unüblich (ich wusste nicht mal das dies geht).
Und es scheiter weil es keine Developing Packete gibt sondern die Header
datein etc werden in Buildroot des SDKs bzw in der Source directory
gespeichert.
Du must das ganze auf dem localem PC mit dem SDK compilieren
Ja, aber kürzer oder später will ich direkt auf dem Target, das ja sehr
viel Ressourcen hat (1 GB RAM) hat, so wie ein kleiner PC, kompilieren
und linken.
Mit "opkg install" kann man ja die Entwicklungsumgebung installieren und
das hat super funktioniert.
Programme ohne spezielle Bibliotheken sind kompilierbar und lauffähig.
Grundsätzlich geht es ja.
Aber was ist an meinem Befehl falsch, dass er fehl schlägt???
root@OpenWrt:~# gcc $CFLAGS $LDFLAGS -lncurses hello.c
hello.c:(.text.startup+0xc): undefined reference to `initscr'
hello.c:(.text.startup+0x18): undefined reference to `printw'
hello.c:(.text.startup+0x1c): undefined reference to `stdscr'
...
Das geht auch nicht, hatte ich schon vorher probiert.
Gerade läuft der make für das SDK.
Ich erhoffe mir von der PC-Seite detailliertere Fehler-Angaben.
@Herr_schrullig
Du scheinst dich mit openwrt auszukennen.
Beim genauen hinsehen würde ich sagen das nicht mal die *.c Datei
übersetzt wird und eigendlich fehlen auch die include anweisungen im gcc
(sowas wie -I/usr/include)
Also der pfad zu den ncurses header dateien allerdings sind die den in
den c dateien mit #include <blah.h> angegeben ?
[quote]
Du scheinst dich mit openwrt auszukennen.
[/quote]
ist irgendwie mein Hobby geworden
Und dann könnte es natürlich auch sein das die ncurses Version in
Openwrt die ensprechenden funktionen tatsächlich nicht kennt das würde
ich mal in der entsprechenden ncurses source mal prüfen.
"Beim genauen hinsehen würde ich sagen das nicht mal die *.c Datei
übersetzt wird und eigendlich fehlen auch die include anweisungen im gcc
(sowas wie -I/usr/include)"
Nee, mit gcc -c hello.c láuft es und es kommt ein hello.o heraus.
Bei includes in Standard Verzeicnissen braucht man kein -I.
vieleicht noch -fno-plt zu den CFLAGS hinzufügen.
(ich habe keine ahnung was das bedeutet, aber das kann man bei
Additional compiler options lesen wenn man make menuconfig aufruft)
Ansonsten habe ic auch keine idee mehr
>> -Wl,-rpath=/usr/lib -Wl,--dynamic-linker=/usr/lib/ -L/usr/lib>> Wozu soll das denn gut sein?
Das war in der /usr/bin/gcc_env.sh enthalten.
Ich vermutete, dass das die richtige Einstellung sein soll, um mit der
Entwicklungsumgebung auf dem Target native Programme zu erstellen.
Die $CFLAGS Einstellungen scheinen ja ganz vernünftig und notwendig.
>> probier mal: gcc $CFLAGS $LDFLAGS hello.c -lncurses> Genau das!
Funktioniert genauso wenig.
Wenn ich auf dem PC kompiliere erhalte ich eine Warning, dass er das
richtige libgcc.so nicht findet.
Vermutlich hat das was mit musl/glibc Verwechslung was zu tun.
Eine Methode zum Finden der richtigen Compiler-Switches wäre, mit dem
Build-Root das Image/rootfs zu erstellen, dabei mit "make V=s | tee
/path/save_my_output"
Dann sieht man nämlich, wie mit welchen Einstellungen die Build-Umgebung
das erledigt, und diese dann kopieren.
Das ist natürlich ein längliches Unterfangen
auf dem openwrt-Forum hat mir jemand geschrieben:
>You will need to install a full build system on the target. A compiler alone >typically doesn't include all the needed headers, link libraries, and tools >required to generate executables.>Getting something that requires curses to run may require files and/or ?>utilities that define the "screen">...
Die include-Dateien waren alle da nach einem "opkg ncurses-dev".
Möglicherweise brauche ich eine andere libncurses.so, weil die
bestehende nur für Runtime-Zwecke erstellt ist, und man keine Sourcen
damit linken kann.
Audio schrieb:>>> -Wl,-rpath=/usr/lib -Wl,--dynamic-linker=/usr/lib/ -L/usr/lib>>>> Wozu soll das denn gut sein?>> Das war in der /usr/bin/gcc_env.sh enthalten.> Ich vermutete, dass das die richtige Einstellung sein soll, um mit der> Entwicklungsumgebung auf dem Target native Programme zu erstellen.> Die $CFLAGS Einstellungen scheinen ja ganz vernünftig und notwendig.
Die LDFLAGS sollten aber so eigentlich nicht nötig sein. Da müsste der
Compiler die richtigen Einstellungen eigentlich mitbringen.
>>> probier mal: gcc $CFLAGS $LDFLAGS hello.c -lncurses>> Genau das!>> Funktioniert genauso wenig.
Hmm, das ist eigenartig. Bei weiteren Versuchen solltest du es aber so
schreiben, denn das ist notwendig.
Auf dem PC kompiliert das Testprogramm problemlos.
Ich habe nur diese paar Befehle ausgeführt, das "make" dauerte aber
lange, fast 3 Stunden.
Aber warum geht das auf dem Target nicht? Die Tools, libs sind ja die
gleichen?!
> das "make" dauerte aber> lange, fast 3 Stunden.
da wurde alles neu erstellt: toolchain, target-images, ... insgesamt
13GiB
Wenn man nur das SDK runterlädt, dann geht das schneller, weil das SDK
für die jeweilige Architektur nur eine Untermenge des build-system ist.
Thread beobachten
Seitenaufteilung abschalten