--with-boxtype=generic

[rhabarber1848]

Hi,

und weiter geht es mit neuen build-Möglichkeiten

seife hat vor kurzem einen guten Vorschlag gemacht:
http://forum.tuxbox-cvs.sourceforge.net ... 10#p367110

wäre es schwierig, ins CDK eine option einzubauen, die das bauen von toolchain und glibc überspringt und stattdessen einen Pfad zu einer fertig gebauten crosstoolchain annimmt? Das würde zum einen das native Bauen erleichtern (einfach den installierten systemcompiler benutzen), ausserdem gibts für meine bevorzugte Distribution seit heute aktuelle crosstoolchains als Paket zum einfachen Installieren

Von einem anonymen Spender habe ich den folgenden,
vor mir bisher ungetesteten, Patch erhalten: cvs_generic.diff

der das Kompilieren mit dem Host-Compiler ermöglichen soll.

To-Do-Liste des Spenders:
- Kernel, bisher nicht berücksichtigt
- libtuxbox verhindert Neutrino-Kompilierung

[seife]

mit dem Host-Compiler habe ich schon komplett durchkompiliert - dazu braucht man kein cdk

Das cdk-enable-prebuilt-toolchain-usage.diff erlaubt es, per

Code: Alles auswählen

./configure --enable-maintainer-mode \
        --enable-flashrules \
        --with-toolchain=/opt/cross \
        --target=powerpc-embed-linux-gnueabi \
        --enable-kernel26

so ziemlich durchzubauen (Annahme: die crosstools sind in /opt/cross und das target heisst "powerpc-embed-linux-gnueabi").
Die Treiber und das u-boot haben noch code, der sich mit neueren Compilern nicht verträgt, aber das ist ein anderes Problem.
Kannst du mal drüberschauen, ob das in Ordnung ist? Ich gehe davon aus, dass es nichts kaputtmachen sollte, aber man weiss ja nie...

Das ist übrigens unabhängig vom boxtype... hm. Eigentlich offtopic hier.

[rhabarber1848]

Kannst du mal drüberschauen, ob das in Ordnung ist?

make targets binutils und bootstrap_gcc sind weiterhin aktiv,
diese sollten IMHO deaktiviert werden.

Warum CC=$(target)-gcc statt $(BUILDENV) bei libfreetype und libz?

[seife]

make targets binutils und bootstrap_gcc sind weiterhin aktiv,
diese sollten IMHO deaktiviert werden.

Sie werden aber nie aufgerufen. Insofern stören sie nicht. Um Verwirrung zu vermeiden könnte man sie aber ausblenden. Ausserdem merkt man dann, wenn sie doch noch irgendwo getriggert werden würden.
Ich habe sie mal ausgeblendet, patch ist aktualisiert.

Warum CC=$(target)-gcc statt $(BUILDENV) bei libfreetype und libz?

Weil es sonst nicht baut, zumindest nicht mit gcc-4.2.4. Irgendwie mögen libfreetype und libz nicht, wenn ihnen zuviel über AR, RANLIB etc. gesagt wird.
Das Kompilieren mit dem normalen CDK funktioniert trotzdem, wohl weil der $(target)-gcc schon weiss, wo er seine kumpels findet.

[rhabarber1848]

patch ist aktualisiert.

sieht gut aus, kann ins CVS

[knight20001]

was haltet ihr denn von folgender config:

#!/bin/bash
cd .. && CURRENT_PATH=`pwd`;
cd cdk
./autogen.sh;
./configure \
--prefix=$HOME/images \
--with-cvsdir=$HOME/tuxbox-rel \
--enable-maintainer-mode \
--with-targetruleset=flash \
--disable-ide

[knight20001]

und warum kann ich aktuell mit dem aktuellen head kein dream image bauen ?
was mach ich denn falsch ?
ich versuche mit :
./prepare dreabox dm500

oder

./prepare dreabox:dm500

oder

./prepare dm500

oder

./prepare dreabox{dm500}

und immer kommt das raus:

summary:
----------------------------------------
target cpu/boxtype: 823/dbox2
kernel: 2.4
used yadd kernel config: Patches/linux-2.4.35.5-dbox2.config
used flash kernel config: Patches/linux-2.4.35.5-dbox2.config-flash
libc: glibc
threads: linuxthreads
target: powerpc-tuxbox-linux-gnu
host: i686-pc-linux-gnu
flash rules: yes
target prefix: /home/mst/images/cdkroot
host prefix: /home/mst/images/cdk
boot prefix: /home/mst/images/tftpboot
build prefix: /home/mst/tuxbox-rel/cdk
root partition size: 0x660000
LZMA support: yes
default locale: deutsch
serversupport: /home/mst/images/serversupport
checkImage: true
target apps directory: /home/mst/tuxbox-rel/apps
boot directory: /home/mst/tuxbox-rel/boot
start script directory: /home/mst/tuxbox-rel/cdk/root
driver directory: /home/mst/tuxbox-rel/driver
host apps directory: /home/mst/tuxbox-rel/hostapps
logo directory: /home/mst/tuxbox-rel/cdk/logos
customization directory: /home/mst/tuxbox-rel/cdk
ucode directory: NONE
GNU server: ftp.gwdg.de/pub/misc/gnu/ftp/gnu
default server: www.tuxbox-cvs.sourceforge.net/cvsdata/files
update http prefix:
used busybox-m4-config: config/busybox.config.m4
IDE support: no
MMC support: no
fstab default fs:
IDE/MMC: Ext2 support no
IDE/MMC: Ext3 support no
IDE/MMC: XFS support no
IDE/MMC: REISERFS support no
IDE/MMC: VFAT support no
CIFS kernel module: yes
SMBFS kernel module: no
LUFS kernel module: yes
NFS kernel module: yes
NFS server: no
Samba server: no
Automount: yes
dosfstools: no
Neutrino UPnP-support: no
Esound support: no
FLAC support: no
German keymaps: no
sqlite3 storage: no
ccache support: no


configure: creating Makefile-archive
configure: creating ./config.status
config.status: creating Makefile
config.status: creating rules-downcheck.pl
config.status: creating root/Makefile
config.status: creating root/etc/Makefile
config.status: creating root/etc/init.d/Makefile
config.status: creating root/etc/network/Makefile
config.status: creating root/share/Makefile
config.status: creating root/share/udhcpc/Makefile
config.status: executing depfiles commands
config.status: executing rules-downcheck-chmod commands


wo ist hier der fehler ???

[seife]

Was hat das bitteschön mit diesem Topic zu tun?

[knight20001]

sorry,

aber ich hänge irgendwie fest und bekomme kein dm500 so gebaut.
ausserdem wusste ich nicht wo es am besten rein passt

[Striper]

Dann mach doch bitte nen neuen Thread auf... oO

[rhabarber1848]

ausserdem wusste ich nicht wo es am besten rein passt

http://forum.tuxbox-cvs.sourceforge.net ... 18&t=45343

[rhabarber1848]

@seife, diesmal on-topic:
z.B.
http://cvs.tuxbox-cvs.sourceforge.net/t ... 15&r2=1.16

Code: Alles auswählen

#if defined HAVE_DBOX_HARDWARE || defined HAVE_DREAMBOX_HARDWARE || defined HAVE_IPBOX_HARDWARE

Warum hast Du nicht

Code: Alles auswählen

# ifndef HAVE_GENERIC_HARDWARE

genutzt? Wenn irgendwann der Coolstream-Code kommt, muss
die o.g. Zeile wahrscheinlich um

Code: Alles auswählen

|| defined HAVE_COOLSTREAM_HARDWARE

erweitert werden, für jeden weiteren Boxtyp würde sich das wiederholen.
Das sieht nicht sehr elegant aus, imho.

[seife]

Ich will irgendwann sowas wie

Code: Alles auswählen

#ifdef LOOKS_LIKE_DBOX

;-)
was dann (momentan) dream, IP und dbox umfassen würde. Evtl. (falls ich die Hardware jemals bekomme) auch noch ITGate. Die Coolstream wird vermutlich eine etwas andere API haben, die wird eher unter "GENERIC + Zusatz" laufen, die Tripledragon ist auch ganz anders.

Im Prinzip ist es meist ein "has_dbox_like_frontprocessor_device"

Aber diese includes hängen eben nicht vom boxtype=generic ab, sondern dieser Header muss momentan auf dbox2, dream und ipbox included werden. Und deswegen habe ich genau das hingeschrieben.

Früher hiess ja "#ifndef HAVE_DREAMBOX_HARDWARE" auch dasselbe wie (das damals noch nicht vorhandene) "#ifdef HAVE_DBOX_HARDWARE", und das war ja auch nicht korrekt.