uclibc patch

[rhabarber1848]

apropos yadd
ich hab das noch nie hinbekommen
mit suse 10.3(bald 11.0)

Schau mal hier: http://forum.tuxbox-cvs.sourceforge.net ... 23&t=48063
Wenn Du noch Fragen kannst, wäre o.g. Thread der richtige Ort.
Es ist wirklich nicht schwer und sehr schön, wenn man ein Image testen kann,
ohne es flashen zu müssen.

[rhabarber1848]

Code: Alles auswählen

make[3]: Leaving directory `/media/disk/tuxbox-uclibc-ide-ext3-xfs-directfb-2008-09-30_22-55/tuxbox-cvs/cdk/e2fsprogs-1.40.8/lib/ext2fs'
[...]
../../lib/libuuid.so: undefined reference to `__tls_get_addr'
collect2: ld returned 1 exit status

Das Hinzufügen von "--disable-tls" zum e2fsprogs-configure hilft.
In der nächsten Version von uclibc.diff wird das enthalten sein.

[rhabarber1848]

@seife: Am uclibc.diff gefällt mir die $gnu_target-Konstruktion und die Links, die nach
dem Kompilieren von gcc angelegt werden, überhaupt nicht. Mittlerweile habe ich heraus-
gefunden, dass das nötig ist, weil ältere Version von config.[sub|guess] mit dem target
powerpc-tuxbox-linux-uclibc nicht umgehen können.

make[1]: Entering directory `/root/tuxbox/work_uclibc2/compile/cdk/freetype-2.1.4'
cd builds/unix; ./configure --build=i686-pc-linux-gnu --host=powerpc-tuxbox-linux-uclibc --prefix=
checking build system type... i686-pc-linux-gnu
checking host system type... Invalid configuration `powerpc-tuxbox-linux-uclibc': machine `powerpc-tuxbox-linux' not recognized
configure: error: /bin/sh ./config.sub powerpc-tuxbox-linux-uclibc failed
make[1]: *** [unix-def.mk] Fehler 1
make[1]: Leaving directory `/root/tuxbox/work_uclibc2/compile/cdk/freetype-2.1.4'

Aktuelle Versionen sind dazu in der Lage.

Nun anstatt einen work-around a'la $gnu_target zu benutzen, dachte ich mir, das Übel
an der Wurzel zu packen. Mein Vorschlag ist, in cdk/Patches aktuelle Versionen der
beiden Dateien vorzuhalten und nach dem Entpacken der Quellcodearchive alle darin
enthaltenen Dateien config.[sub|guess] zu löschen und mit der jeweiligen Version
in cdk/Patches zu verlinken.

Das klappt hier schon ganz gut und kann unabhängig von uclibc.diff genutzt werden.

Pakete, die ohne neue config.[sub|guess] oder die $(gnu_target)-Konstruktion mit
uclibc mit Sicherheit nicht kompilieren, sind bash, modutils, libsigc, readline, freetype.
Wahrscheinlich gibt es noch mehr davon.

Bist Du mit meinem Plan einverstanden?

PS: Der Patch besteht aus config.[sub|guess] und einem Einzeiler in rules.pl
PPS: Hier ist der Patch: EDIT: Patch ist im CVS

[seife]

Das hört sich nach einem guten Plan an. Das $gnu_target fand ich auch nicht so berauschend

Ich bin allerdings nicht so der toolchain-Spezialist, insofern ist meine Meinung da eher zweitrangig.

[rhabarber1848]

PPS: Hier ist der Patch: config.diff

Der daran angepasste uclibc.diff ist nun nur noch 42kb statt 70kb groß

[amiga23]

ich teste gerade mit config.diff und uclibc.diff. seife hat inzwischen den timerd part aus uclibc.diff ins cvs eingecheckt.

[rhabarber1848]

PPS: Hier ist der Patch: config.diff

Der daran angepasste uclibc.diff ist nun nur noch 42kb statt 70kb groß

Der daran angepasste uclibc.diff ist noch gar nicht veröffentlicht, da ich noch Kompiliertests laufen lasse.
config.diff ist IMHO allerdings schon CVS-ready und kann ohne uclibc.diff genutzt werden.

[seife]

config.diff ist IMHO allerdings schon CVS-ready und kann ohne uclibc.diff genutzt werden.

JAJAJA! Ich mach ja schon

...kann man denn hier nicht mal mehr in Ruhe ins Wochenende fahren...

[amiga23]

okay, ich habe also mit config.diff und dem alten uclibc.diff gebaut. Ergebnis ist wieder, daß neutrino nicht hochkommt und sich über libpng12 beschwert, wie oben beschrieben. ist also reproduzierbar.

[amiga23]

@Tommy und rhabarber1848 zum Thema YADD
Kann man mit einer YADD wirklich ein Image testen? Das YADD verwendet doch die Dateien in dbox2/cdkroot
Somit könnte ich zwar prinzipielle Dinge testen, aber nicht 100%ig ob ein Image auch wirklich funktioniert.

Die einzigen "Probleme" die ich mit YADDs habe sind:
1. DHCP muss ich im Router abschalten, damit es nicht mit dem YADD Rechner kollidiert. Das ist nervig, weil ich für den Firmenlaptop DHCP benötige. Habe keine Lust jedesmal die IP per Hand umzustellen.
2. Häufig bootet die Box doch direkt aus dem Image und nicht über DHCP/TFTP, so dass ich Pfeil nach oben gedrückt halten muss und dann über seriell "boot net" eingeben muss. (Für mich als Hesse, ist es übrigens lustig, dass "boot NET" eben doch das Gegenteil macht ;-) )

Meine Intention im Moment ist es seife und rhabarber1848 beim testen zu helfen. Dazu baue ich lieber images anstatt yadds, dann sind wir auf der sicheren Seite.

[dbt]

Kann man mit einer YADD wirklich ein Image testen? Das YADD verwendet doch die Dateien in dbox2/cdkroot

An YADD wirst du so auf Dauer trotzdem nicht drumherum kommen. Es ist schon ein Unterschied ob man zum testen von nur einer Minizeile im Code 10 Minuten oder weniger als 1 Minute braucht. Rechne dir's aus, vorallem wie lange dein Geduldsfaden das durchält. Das ist auf Dauer kein Spass.

Somit könnte ich zwar prinzipielle Dinge testen, aber nicht 100%ig ob ein Image auch wirklich funktioniert.

Schon richtig, aber führe dir das Prinzip bitte vor Augen. Du kanst alles testen und durchspielen, und wenn's dann läuft ein Image backen. Wenns dann nicht geht muss man dann sehen wo's hängt. Also den Aufwand, ein YADD einzurichten, würde ich vorziehen.

[amiga23]

Ja ihr habt ja recht.

@rhabarber1848: habe eben ein Image mit (altem) uclibc.diff aber ohne --enable-uclibc gebaut. Kompiliert durch. 2xI-Image geflashed und Neutrino funktioniert.
links geht nicht, da ihm Symbole im glibc fehlen, aber das ist ja auch klar, wurde ja reduced.

[rhabarber1848]

Somit könnte ich zwar prinzipielle Dinge testen, aber nicht 100%ig ob ein Image auch wirklich funktioniert.

Das stimmt, Du kannst aber per Yadd dennoch testen, ob eine Binary überhaupt
funktioniert, da der verwendete Quellcode der gleiche ist.

1. DHCP muss ich im Router abschalten, damit es nicht mit dem YADD Rechner kollidiert. Das ist nervig, weil ich für den Firmenlaptop DHCP benötige. Habe keine Lust jedesmal die IP per Hand umzustellen.

Ich habe ein ähnliches Problem, der DHCP-Daemon auf meinem Server ist leider
so alt, dass er mit der Dbox nicht klar kommt. Deshalb nutze ich DHCP/Bootp
von meiner Workstation aus, gleichzeitig habe ich Bootp-Support für die Dbox
auf dem Server deaktiviert:

Code: Alles auswählen

    host dbox
    {
        deny bootp;
        hardware ethernet 00:50:9C:38:xx:xx;
        fixed-address 192.168.x.x;
    }

Auf meiner Workstation gibt es für DHCP nur einen Eintrag:

Code: Alles auswählen

allow bootp
[...]
host dbox {
        fixed-address 192.168.x.x;
        hardware ethernet 00:50:9C:38:xx:xx;
        server-name "192.168.x.y";
        next-server 192.168.x.y;
        option root-path "/root/tuxbox/work/image/cdkroot";
        if exists vendor-class-identifier {
                filename "/root/tuxbox/work/image/tftpboot/kernel-cdk";
        } else {
                filename "/root/tuxbox/work/image/tftpboot/u-boot";
        }
}

Damit kommen sich die beiden DHCP-Server nicht in die Quere.

2. Häufig bootet die Box doch direkt aus dem Image und nicht über DHCP/TFTP

Bekanntes Problem mit Sagem-Boxen, ich habe selber eine. Der Bootmanager der
Dbox sendet nur beim Kaltstart einen Bootp-Request. Deshalb setze ich die Dbox
in den deep-standby und schalte sie per Fernbedienung wieder an, dann klappt Bootp.

[rhabarber1848]

Der daran angepasste uclibc.diff ist noch gar nicht veröffentlicht, da ich noch Kompiliertests laufen lasse.

Die Tests laufen noch, momentan habe ich das Problem, dass mklibs.py in einer
Endlosschleife landet, weil 2 Symbole nicht aufgelöst werden können. Es kann
sein, dass das mit --enable-ide o.ä. zu tun hat, ich habe viele Optionen aktiviert,
um möglichst viele Pakete mit uClibc testen zu können. Evtl. muss ich bei
e2fsprogs noch -fPIC hinzufügen, das muss ich noch testen. Ich glaube nicht,
dass ich heute noch eine neue Version von uclibc.diff veröffentlichen kann.
Also genießt den Feiertag

[rhabarber1848]

links geht nicht, da ihm Symbole im glibc fehlen, aber das ist ja auch klar, wurde ja reduced.

Könntest Du die configure-Optionen und andere Infos zu links posten?
Dann baue ich das in rules-make/archive ein.

[rhabarber1848]

momentan habe ich das Problem, dass mklibs.py in einer
Endlosschleife landet, weil 2 Symbole nicht aufgelöst werden können.

Zum allgemeinen Testen habe ich den Patch dennoch aktualisiert, obwohl das
mklibs.py-Problem noch enthalten ist. Es tritt allerdings bei Vermeidung der
u.g. Optionen nicht auf. Ich teste nun, welche Option dafür verantwortlich ist.

Hier der aktuelle uClibc-Patch: uclibc.diff

Changelog:
- (03.10.2008): Update für aktuelles CVS, $gnu_target entfernt da veraltete config.[sub|guess] nun aktualisiert werden
- (03.10.2008): aktuelle Version von netfile-uclibc.patch eingebaut
- (03.10.2008): Kompilierproblem in e2fsprogs behoben
- (03.10.2008): Linkproblem in lcdmenu behoben, tritt scheinbar nur mit uClibc auf
[...]
- Endlosschleife in mklibs.py, eine dieser configure-Optionen ist dafür verantwortlich: "--enable-ide --enable-upnp --enable-flac", ohne diese Optionen funktioniert mklibs.py. Vermutung: libuuid.so aus e2fsprogs benötigt "-fPIC"

[rhabarber1848]

Ich teste nun, welche Option dafür verantwortlich ist.

--enable-ide scheint zu funktionieren, e2fsprogs ist scheinbar nicht die Ursache.

Teste nun --enable-flac

PS: Mit --enable-flac tritt das Problem auf. Ich lasse gerade die Gegenprobe ohne
--enable-flac durchlaufen. Komisch nur, dass libFLAC bereits mit $(BUILDENV_LIBS)
kompiliert wird. Ich muss mir das Paket dann mal genauer ansehen...

cd flac-1.2.0 && \
AR=powerpc-tuxbox-linux-uclibc-ar AS=powerpc-tuxbox-linux-uclibc-as CC=powerpc-tuxbox-linux-uclibc-gcc CXX=powerpc-tuxbox-linux-uclibc-g++ NM=powerpc-tuxbox-linux-uclibc-nm RANLIB=powerpc-tuxbox-linux-uclibc-ranlib CFLAGS="-pipe -Os" CXXFLAGS="-pipe -Os" LDFLAGS="-Wl,-O1" PKG_CONFIG_PATH=/root/tuxbox/work_uclibc_ide_flac/image/cdkroot/lib/pkgconfig CFLAGS="-pipe -Os -fPIC" \
./configure \
[...]
checking for powerpc-tuxbox-linux-uclibc-gcc option to produce PIC... -fPIC
checking if powerpc-tuxbox-linux-uclibc-gcc PIC flag -fPIC works... yes
[...]
checking for powerpc-tuxbox-linux-uclibc-g++ option to produce PIC... -fPIC
checking if powerpc-tuxbox-linux-uclibc-g++ PIC flag -fPIC works... yes

PPS: Gegenprobe bestanden, ohne --enable-flac läuft mklibs.py durch, mit FLAC nicht.
Ich teste nun flac-1.2.1, wenn das nicht hilft, geht das patchen los...

[rhabarber1848]

PPS: Gegenprobe bestanden, ohne --enable-flac läuft mklibs.py durch, mit FLAC nicht.
Ich teste nun flac-1.2.1, wenn das nicht hilft, geht das patchen los...

Ich bin immer noch nicht weitergekommen, weil ich scheinbar zu wenig vom cross-compile verstehe...
Also möchte ich erstmal meine Ergebnisse zeigen:

./configure ... --enable-flac ... && make flash-neutrino-squashfs-all
endet in einer Endlosschleife von mklibs.py

Still need: __thenan_sf
Still need: __fpcmp_parts_f
1091 symbols, 2 unresolved

Die Symbole __fpcmp_parts_f und __thenan_sf werden von libgcc_s.so zur Verfügung gestellt.
Diese Datei wird erst beim zweiten gcc-compile erzeugt.
Alle .so-Dateien mit diesem Symbol[1], außer libm.so, sind u.a. gegen libgcc_s.so gelinkt.
libm.so gehört zu uClibc und wird vor dem zweiten gcc-compile erzeugt.
Daher kann libm.so nicht gegen die zu diesem Zeitpunkt noch nicht
existierende Datei libgcc_s.so gelinkt werden.

Nun meine Fragen:
- mklibs.py zeigt, trotz DEBUG_SPAM, nur die nicht auflösbaren Symbole an, leider nicht, welche Datei diese Meldung auslöst. Abhilfe?
- ist libm.so wirklich dafür verantwortlich? neutrino und libFLAC.so sind beide gegen libm.so gelinkt, sodass mklibs.py eigentlich alle Symbole finden müsste

[1] libpng gehört auch dazu, möglicherweise ist das auch die Ursache des nicht bootenden uClibc-flashimages

[rhabarber1848]

Hier der aktuelle uClibc-Patch: uclibc.diff

Changelog:
- (05.10.2008): ./configure --enable-flac --enable-uclibc bricht mit Fehlermeldung ab, da FLAC zu einer Endlosschleife in mklibs.py führt
- (05.10.2008): uClibc .config: DO_C99_MATH testweise deaktiviert (libm.so wird dadurch 43kb kleiner)

Ich habe meine Bemühungen hinsichtlich FLAC nun eingestellt, ich finde keine Lösung.
Da FLAC ohnehin nur optional ist und viel Speicher im Image benötigt, lohnt es sich
für mich nicht, weitere Zeit für eine Lösung zu investieren.

[Houdini]

Die Frage ist auch, ob man mklibs mit der uClibc überhaupt machen will,
wenn nicht hat man das "Problem" der unresolved symbols aus der Welt

[rhabarber1848]

hab eben ein uclibc-2.4 image geflashed.

Code: Alles auswählen

neutrino: symbol '': can't handle reloc type 0x6 in lib '/lib/libpng12.so.0'
Neutrino exited with nonzero exit status, restarting...

Mit dem neuesten uclibc.diff tritt das Problem nicht auf, ich habe gerade
ein uclibc-Neutrino-Squashfs-Image getestet. Vermutlich liegt es an
der deaktivierten C99-Unterstützung, die schon früher solche Probleme
verursachte: http://uclibc.org/lists/uclibc/2005-Dec ... 13731.html

Leider hilft das mit dem FLAC-Problem nicht weiter...

[Carjay]

Nun meine Fragen:
- mklibs.py zeigt, trotz DEBUG_SPAM, nur die nicht auflösbaren Symbole an, leider nicht, welche Datei diese Meldung auslöst. Abhilfe?

Probier mal den Patch hier, er zeigt beim "Still need" dann auch die Programme/Libs an, welche dieses Symbol benötigen:

ftp://ftp.berlios.de/pub/tuxbox/misc/mk ... iff.tar.gz

[rhabarber1848]

Hier der aktuelle uClibc-Patch: uclibc.diff

Changelog:
- (08.10.2008): Kompilierfehler in sambaserver behoben
- (08.10.2008): Kompilierfehler in nfs-utils behoben (getgrouplist existiert nicht in uClibc, Backport von getrpcbynumber_r (1, 2) nach uClibc 0.29.8.3)
- (08.10.2008): ld-uClibc-0.9.28.so und ld-uClibc.so.0 sind nicht mehr doppelt im Flashimage enthalten
- (08.10.2008): ./configure --enable-xfs --enable-uclibc bricht mit Fehlermeldung ab, da nicht kompilierbar

Die nächste Version...

Hier ist das komplette Posting: http://forum.tuxbox-cvs.sourceforge.net ... 37#p360937

[rhabarber1848]

hab eben ein uclibc-2.4 image geflashed.

Code: Alles auswählen

neutrino: symbol '': can't handle reloc type 0x6 in lib '/lib/libpng12.so.0'
Neutrino exited with nonzero exit status, restarting...

Mit dem neuesten uclibc.diff tritt das Problem nicht auf, ich habe gerade
ein uclibc-Neutrino-Squashfs-Image getestet. Vermutlich liegt es an
der deaktivierten C99-Unterstützung,

Stimmt nicht, mit dem aktuellen uclibc.diff + manuell aktivierter C99-Unterstützung
bootet ein Neutrino-flashimage ohne Probleme. Gut, pulseaudio braucht nämlich C99.

@amiga23: Ich kann den Bug also nicht reproduzieren. Tritt er bei Dir mit dem aktuellen
Patch noch auf?

[rhabarber1848]

Probier mal den Patch hier, er zeigt beim "Still need" dann auch die Programme/Libs an, welche dieses Symbol benötigen:

ftp://ftp.berlios.de/pub/tuxbox/misc/mk ... iff.tar.gz

Danke, habe ich gemacht, nur leider: "Da steh' ich nun, ich armer Tor, und bin so klug als wie zuvor."

I: library reduction pass 10
Still need: __thenan_sf, needed by: /root/tuxbox/work_uclibc_flac/image/cdkflash/root-neutrino-squashfs/lib/libFLAC.so.8-so-stripped, /root/tuxbox/work_uclibc_flac/image/cdkflash/root-neutrino-squashfs/lib/libFLAC.so.8-so-stripped, /root/tuxbox/work_uclibc_flac/image/cdkflash/root-neutrino-squashfs/lib/libFLAC.so.8-so-stripped, /root/tuxbox/work_uclibc_flac/image/cdkflash/root-neutrino-squashfs/lib/libFLAC.so.8-so-stripped, /root/tuxbox/work_uclibc_flac/image/cdkflash/root-neutrino-squashfs/lib/libFLAC.so.8-so-stripped, /root/tuxbox/work_uclibc_flac/image/cdkflash/root-neutrino-squashfs/lib/libFLAC.so.8-so-stripped, /root/tuxbox/work_uclibc_flac/image/cdkflash/root-neutrino-squashfs/lib/libFLAC.so.8-so-stripped, /root/tuxbox/work_uclibc_flac/image/cdkflash/root-neutrino-squashfs/lib/libFLAC.so.8-so-stripped, /root/tuxbox/work_uclibc_flac/image/cdkflash/root-neutrino-squashfs/lib/libFLAC.so.8-so-stripped
Still need: __fpcmp_parts_f, needed by: /root/tuxbox/work_uclibc_flac/image/cdkflash/root-neutrino-squashfs/lib/libFLAC.so.8-so-stripped, /root/tuxbox/work_uclibc_flac/image/cdkflash/root-neutrino-squashfs/lib/libFLAC.so.8-so-stripped, /root/tuxbox/work_uclibc_flac/image/cdkflash/root-neutrino-squashfs/lib/libFLAC.so.8-so-stripped, /root/tuxbox/work_uclibc_flac/image/cdkflash/root-neutrino-squashfs/lib/libFLAC.so.8-so-stripped, /root/tuxbox/work_uclibc_flac/image/cdkflash/root-neutrino-squashfs/lib/libFLAC.so.8-so-stripped, /root/tuxbox/work_uclibc_flac/image/cdkflash/root-neutrino-squashfs/lib/libFLAC.so.8-so-stripped, /root/tuxbox/work_uclibc_flac/image/cdkflash/root-neutrino-squashfs/lib/libFLAC.so.8-so-stripped, /root/tuxbox/work_uclibc_flac/image/cdkflash/root-neutrino-squashfs/lib/libFLAC.so.8-so-stripped, /root/tuxbox/work_uclibc_flac/image/cdkflash/root-neutrino-squashfs/lib/libFLAC.so.8-so-stripped

Also libFLAC.so, in der Datei gibt es die ASCII-Sequenzen __fpcmp_parts_f und __thenan_sf, im
libFLAC-Sourcecode allerdings nicht. Aber nun gut, in libm.so.0-so (48276 Byte) gibt es diese ASCII-Sequenzen
auch, wohingegen in libm.so.0-so-stripped (23380 Byte) dies nicht mehr der Fall ist. Es scheint also,
mklibs.py hätte diese Symbole entfernt. Aber warum, wenn sie benötigt werden?