@seife compile error

[bazi98]

habe das neutrino-mp neu aufgesetzt für eine CST ZEE , bis hier hin ist alles durchgelaufen...

Code: Alles auswählen

make[5]: Betrete Verzeichnis '/home/user/coolstream/seife/build_tmp/neutrino-mp/src'
  CXX    neutrino_menue.o
  CXX    neutrino.o
  CXXLD  neutrino
  CC     rcsim.o
  CCLD   rcsim
  CC     drivertool.o
  CCLD   drivertool
  CC     dt.o
  CCLD   dt
  CXX    uncoolinit.o
/home/user/coolstream/seife/source/neutrino-mp/src/uncoolinit.cpp: In function 'int main(int, char**)':
/home/user/coolstream/seife/source/neutrino-mp/src/uncoolinit.cpp:43:23: error: 'sleep' was not declared in this scope
make[5]: *** [uncoolinit.o] Fehler 1
make[5]: Verlasse Verzeichnis '/home/user/coolstream/seife/build_tmp/neutrino-mp/src'
make[4]: *** [all-recursive] Fehler 1
make[4]: Verlasse Verzeichnis '/home/user/coolstream/seife/build_tmp/neutrino-mp/src'
make[3]: *** [all] Fehler 2
make[3]: Verlasse Verzeichnis '/home/user/coolstream/seife/build_tmp/neutrino-mp/src'
make[2]: *** [all-recursive] Fehler 1
make[2]: Verlasse Verzeichnis '/home/user/coolstream/seife/build_tmp/neutrino-mp'
make[1]: *** [all] Fehler 2
make[1]: Verlasse Verzeichnis '/home/user/coolstream/seife/build_tmp/neutrino-mp'
make: *** [/home/user/coolstream/seife/deps/neutrino] Fehler 2
user@ubuntu:~/coolstream/seife$ 

ich denke etwas fehlt noch in der "neuen" uncoolinit.cpp

[seife]

was verwendest du denn für einen gcc? mein buildsystem kann das eher nicht sein, sonst wäre es beim durchlauf der Testsuite aufgefallen, denke ich...

[bazi98]

@seife,
gcc 4.71 denke ich , das ich mit bs-wittis System gebaut hatte und den MP-Ordner zu Verfügung gestellt habe.

Edit: die config fürs Buildsystem sieht ansonsten so aus

Code: Alles auswählen

PLATFORM=coolstream
FLAVOUR=neutrino-mp
MAINTAINER = bazi98
LOCAL_NEUTRINO_BUILD_OPTIONS = --enable-upnp

[seife]

sollte nun bis inklusive 4.8 funktionieren.

Ich muss wohl doch mal mein yocto-overlay fertig machen um den coolstream code auch mit aktuellen compilern zu testen...

[bazi98]

@seife,
jepp, das war es, neutrino hat durch gebaut

[bazi98]

@seife,
da ich dich schon an der Leine habe
make plugins bricht auf der coolie ebenfals beim bauen ab

Code: Alles auswählen

make[1]: Betrete Verzeichnis '/home/user/coolstream/seife/build_tmp/neutrino-hd-plugins'
make  all-recursive
make[2]: Betrete Verzeichnis '/home/user/coolstream/seife/build_tmp/neutrino-hd-plugins'
Making all in tuxcom
make[3]: Betrete Verzeichnis '/home/user/coolstream/seife/build_tmp/neutrino-hd-plugins/tuxcom'
arm-cx2450x-linux-gnueabi-gcc -DHAVE_CONFIG_H -I. -I/home/user/coolstream/seife/source/neutrino-hd-plugins/tuxcom -I..  -I/include/freetype2 -I/include -I/home/user/coolstream/seife/source/neutrino-hd-plugins/include   -Wall -W -Wshadow -g -O2 -fno-strict-aliasing -rdynamic -DNEW_LIBCURL  -MT tuxcom.o -MD -MP -MF .deps/tuxcom.Tpo -c -o tuxcom.o /home/user/coolstream/seife/source/neutrino-hd-plugins/tuxcom/tuxcom.c
In file included from /home/user/coolstream/seife/source/neutrino-hd-plugins/tuxcom/tuxcom.c:27:0:
/home/user/coolstream/seife/source/neutrino-hd-plugins/tuxcom/tuxcom.h:55:22: fatal error: ft2build.h: No such file or directory
compilation terminated.
make[3]: *** [tuxcom.o] Fehler 1
make[3]: Verlasse Verzeichnis '/home/user/coolstream/seife/build_tmp/neutrino-hd-plugins/tuxcom'
make[2]: *** [all-recursive] Fehler 1
make[2]: Verlasse Verzeichnis '/home/user/coolstream/seife/build_tmp/neutrino-hd-plugins'
make[1]: *** [all] Fehler 2
make[1]: Verlasse Verzeichnis '/home/user/coolstream/seife/build_tmp/neutrino-hd-plugins'
make: *** [plugins] Fehler 2
user@ubuntu:~/coolstream/seife$ 

[seife]

ja, da ist freetype2 kaputt. Aber das fixe ich im buildsystem eher nicht mehr, vor ich da mit dem Pfusch weitermache nehme ich dann doch lieber yocto/OE, das ist weniger schmerzhaft ;-)

[bazi98]

ja, da ist freetype2 kaputt. Aber das fixe ich im buildsystem eher nicht mehr..

schade, aber ist deine Entscheidung

[seife]

mit OE und yocto im speziellen wird das alles wesentlich einfacher, insbesondere weil die "Grundausstattung" (wie freetype) von Leuten maintained wird, die sich auskennen, dafür bezahlt werden und die wissen was sie tun. Insofern ist das kein Grund zur Trauer

Dann kann ich mich auf die interessanten Sachen konzentrieren und muss nicht ständig die Löcher im Sieb stopfen.


Edit: na gut, das loch war klein, drum habe ich es doch noch gestopft

[bazi98]

thx.
Das mit den "yocto-overlay" hört sich interessant an, aber für mich ist sowas ein paar Hausnummern zu hoch

[doc]

Wieso?
Das Problem mit einer guten Buildumgebung für embedded Geräte habe ja noch viele andere Entwickler und auch Firmen. OE kennt wohl jeder da es eine der ersten Lösungen für so etwas war. OE ist aber nicht gerade für Schnelligkeit bekannt. Yocto ist eine andere Lösung, und hat auch einen anderen Ansatz zur Lösung des Problem der Trennung von der eigentlichen Software und dem darunterliegenden hardwarespezifischen System.

Wer für mehrere Hardwareplattformen bauen will oder muss hat diverse Dinge zu beachten. Das kann viel wertvolle Zeit kosten, hat ja jeder wohl schon mehrfach durch die Probleme die bei den unterschiedlichen Buildumgebungen für die CST Boxen selbst heraus gefunden. Yocto, ptxDist ext. nimmt einem dies ab. Jedoch muss man sich etwas damit auseinander setzen wie das Ganze funktioniert. Im Prinzip wie immer, die Welt dreht sich weiter, wer vorne dabei sein will muss dem anpassen.

[seife]

so, das baut bei mir schon mal ein neutrino und ein rootfs (ext3), welches im qemu bootet und dem scheinbar nichts wichtiges fehlt

https://github.com/seife/meta-coolstream
https://github.com/seife/meta-neutrino-mp

[flk]

funktioniert bestens ...

ich musste nur in meta-neutrino-mp/recipes-local/lua/lua5.2_5.2.1.bb

Code: Alles auswählen

#DEPENDS += "readline"

einkommentieren.

Ausserdem hat bei mir irgendwie die md5 Summe bei openthreads nicht gestimmt. Aber ansonsten ist alles fehlerfrei durchgelaufen. Das rausgekommene Image läuft auf meiner Zee und bringt Fernsehbild. Ich habe allerdings erst mal keinen telnet Zugriff.

[seife]

Ja, telnet ist nicht drin, das muss man noch bauen / einschalten wenn man das will. Warum readline nötig ist ist mir unklar, das habe ich extra rausgemacht, weil das insgesamt das ganze aufbläst und die coolstreams ja keinen platz im flash haben. Das mit der openthreads checksumme schaue ich mir auch nochmal an; bei mir hats funktioniert.

[flk]

Ohne readline hat lua nicht gebaut.

Code: Alles auswählen

lua.c:67:31: fatal error: readline/readline.h: No such file or directory

[flk]

Kann man denn auch opk bauen ?

# Options are:
# - 'package_deb' for debian style deb files
# - 'package_ipk' for ipk files are used by opkg (a debian style embedded package manager)
# - 'package_rpm' for rpm style packages

[seife]

Ja klar,

PACKAGE_CLASSES ?= "package_ipk package_rpm"

in conf/local.conf
package_rpm kannst du auch raus lassen wenn du es nicht brauchst.

[flk]

Ah, dann kann opkg auch mit ipk Paketen umgehen ?!

In der busybox config waren telnetd und ftpd "not set". Ich habe das in ´meta/recipes-core/busybox/busybox-1.21.1/defconfig´ geändert. Passt das so ? Funktioniert hat s jedenfalls. Ich kenn mich noch gar nicht so richtig aus mit dem yocto ... der volle Funktions Overkill

[seife]

ipk und opk ist dasselbe.

Das mit der defconfig passt als quick hack, aber ich würde nie was an den Yocto-Layern ändern sondern stattdessen im meta-neutrino-mp ein override machen:

Code: Alles auswählen

seife@susi:~/yocto-poky/meta-neutrino-mp> l recipes-custom/busybox/
total 4
drwxr-xr-x 3 seife users  57 26. Nov 16:07 ./
drwxr-xr-x 3 seife users  20 26. Nov 10:38 ../
drwxr-xr-x 2 seife users  85 26. Nov 17:29 busybox-1.21.1/
-rw-r--r-- 1 seife users 238 26. Nov 16:07 busybox_1.21.1.bbappend
seife@susi:~/yocto-poky/meta-neutrino-mp> cat recipes-custom/busybox/busybox_1.21.1.bbappend
FILESEXTRAPATHS_prepend := "${THISDIR}/${P}:"
SRC_URI += "file://neutrino-busybox.cfg"
PACKAGES_prepend += "${PN}-inetd"
FILES_${PN}-inetd = " \
        /etc/init.d/inetd.busybox \
        /etc/inetd.conf"
RRECOMMENDS_${PN} += "${PN}-inetd"
seife@susi:~/yocto-poky/meta-neutrino-mp>cat recipes-custom/busybox/busybox-1.21.1/neutrino-busybox.cfg
CONFIG_FEATURE_EDITING_HISTORY=50
CONFIG_FEATURE_VERBOSE_CP_MESSAGE=y
CONFIG_FEATURE_DD_IBS_OBS=y
CONFIG_FEATURE_DF_FANCY=y
CONFIG_FEATURE_PRESERVE_HARDLINKS=y
...

In der neutrino-busybox.cfg sind dann nur die optionen drin, die von der yocto-standardconfig abweichen. Das ist in der meta/recipes-core/busybox/busybox.inc so als "override-mechanismus" vorgesehen.

Irgendwann die Tage mache ich das fertig und checke es ein.

Ja, es gibt einen Haufen Features, und man muss sich ein wenig einarbeiten, aber mit dem meisten muss man sich nicht auseinandersetzen, weil die defaults einfach funktionieren. Und gefühlt ist es wesentlich weniger aufwändig als die alten Makefiles zu warten.

[flk]

Wird s denn auch noch ein zusätzliches Layer für andere Programme geben ? In Sachen UPnP habe ich in den yocto Layern nämlich nichts gefunden und deshalb ein paar Recipes zusammengebastelt und angepasst. Funktioniert bei mir schon fast alles wie mit dem alten Image. Usb-Sticks werden nicht automatisch gemounted, nach reboot aber erkannt. Dann ist mir noch aufgefallen, dass Neutrino nach einem Neustart die Einstellung für den Nameserver verliert, wenn das Netzwerk statisch konfiguriert ist.

Da kann man viel zu viele Pakete bauen für den kleinen Flashspeicher

recipes-support.tar.gz

[seife]

Ich denke es wäre sinnvoller / effizienter, einfach meta-openembedded mit einzubinden. Ich mach mir da aber irgendwann mal Gedanken drüber

[flk]

Nur kein Stress, in den yocto Layern ist ja wirklich schon viel drin. Bin schon am überlegen, ob ich zukünfig von usb booten sollte. Das Image wird schon ein bisschen größer, als mit deinem BS. Da kriegst mit dem Flash in der Zee schnell Probleme.

[seife]

Ich boote nur von USB. Da kann ich im FLASH ein originalimage haben damit ich sehe, ob was kaputtes von der Hardware oder meinen Patches kommt. Ausserdem bootet es schneller.

Ich muss nur mal noch einen schönen "U-Boot-Installer" machen, den man auf der box ausführt und der das bootlogo patched und die U-Boot-Config ändert (wenn das geht), dann ist das deppentauglich. Andererseits muss man das mit der U-Boot-Config ja nur einmal machen...

Achso: bei mir ist das jffs2 image 20MB, ist das soviel größer als vorher? evtl. könnte man ja noch Zeug weglassen.

[flk]

Die U-Boot config hatte ich nach Deiner Anleitung schon vor Jahren geändert, habe das aber selten verwendet, weil s mich optisch immer gestört hat, dass vorne der Stick stecken muss. Ausserdem habe ich nicht viele Sticks, mit denen das auch funktioniert und meistens sind die grad irgendwo verschwunden, wenn ich sie bräuchte. So ganz nackt ist ein jffs2 bei mir genauso groß, aber mit den UPNP-Paketen und nano .... ja, geht auch ohne ...... sind es dann schon über 23 MB. Das ließe sich bestimmt noch in den Recipes optimieren, aber ob das sinnvoll ist, soviel Abhängigkeiten über Bord zu werfen, bloß weil die alten Kisten nicht mehr Speicher haben. Ich habe es jedenfalls schon wieder geschafft, den Flash volllaufen zu lassen. Das ist gefährlich mit dem opkg. Denke schon eine Weile über einen Hardware Wechsel nach, weiß aber nicht wirklich, wofür ich mich entscheiden soll. Das Image ist jetzt auf einen 4GB Stick installiert, der schnellere Bootvorgang ist deutlich spürbar.

[lintux]

Ich boote nur von USB. Da kann ich im FLASH ein originalimage haben damit ich sehe, ob was kaputtes von der Hardware oder meinen Patches kommt. Ausserdem bootet es schneller.
Ich muss nur mal noch einen schönen "U-Boot-Installer" machen, den man auf der box ausführt und der das bootlogo patched und die U-Boot-Config ändert (wenn das geht), dann ist das deppentauglich. Andererseits muss man das mit der U-Boot-Config ja nur einmal machen...

Hi@seife,
Was nutzt du für einen Receiver?

thanks.