libc-so.6, hddtemp und fehlende nl_langinfo

Kreuzuebersetzer, Diskussion über Änderungen im Tuxbox-CDK und Tuxbox-CVS
FlashErase
Neugieriger
Neugieriger
Beiträge: 14
Registriert: Mittwoch 5. September 2007, 18:25

libc-so.6, hddtemp und fehlende nl_langinfo

Beitrag von FlashErase »

Hi Leute,

muß wieder mal eine totale Noob-Frage loswerden. Ich versuche verzweifelt, hddtemp 0.3 beta 15 für das Image zu bauen. Obwohl in der YADD alles richtig läuft, bringt es im Image eingebaut die Meldung.
/sbin/hddtemp: relocation error: /tmp/hddtemp: symbol nl_langinfo, version GLIBC_2.0 not defined in file libc.so.6 with link time reference
Dabei habe ich schon versucht, dem make beizubringen, daß in der glibc kein nl_langinfo drin ist. Den Schalter scheint es aber zu ignorieren. Hier mal mein Config-Aufruf für hddtemp:

Code: Alles auswählen

./configure --disable-nls --disable-langinfo --host=powerpc-tuxbox-linux-gnu --prefix=/home/image/dbox2/cdkroot --with-db-path=/etc/hddtemp.db --without-debug CC=powerpc-tuxbox-linux-gnu-gcc CXX=powerpc-tuxbox-linux-gnu-g++ build_alias=i686-suse-linux host_alias=powerpc-tuxbox-linux-gnu
Hilft aber nicht. Gibt es einen Schalter beim Bauen der libc, daß nl_langinfo mit gelinkt wird oder einen anderen Schalter für das hddtemp-make? Ich würde nämlich gern die statisch gelinkte Variante von über 400 kB gegen die dynamisch gelinkte mit 30 kB austauschen.
Und was wird in der YADD anders gebaut weil da ja das dynamisch gelinkte hddtemp funktioniert?
Zuletzt geändert von FlashErase am Freitag 7. September 2007, 13:06, insgesamt 1-mal geändert.
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Beitrag von seife »

Du mußt dein hddtemp vor dem mklibs.py-Aufruf in "make rebuild-flash" im cdkflash-Baum liegen haben.
mklibs.py stripped aus der libc alles raus, was von keinem Binary benötigt wird, berücksichtigt werden aber natürlich nur die Binaries, die später ins Flash sollen.

Zumindest habe ich das so verstanden (und bei mir funktioniert es so :-)
FlashErase
Neugieriger
Neugieriger
Beiträge: 14
Registriert: Mittwoch 5. September 2007, 18:25

Beitrag von FlashErase »

Hallo seife,

danke für die Antwort. Stellt sich aber gleich die neue Frage, wann das passieren muß und in welches der der Root-Verzeichnisse hddtemp kopiert werden muß. Genügt es, das in der root-local.sh einzubauen und hddtemp nach $HOME/dbox/cdkflash/root/sbin/ zu kopieren? Und genügt anschließend ein "make flash-clean" vor dem Start?
FlashErase
Neugieriger
Neugieriger
Beiträge: 14
Registriert: Mittwoch 5. September 2007, 18:25

Beitrag von FlashErase »

Danke, hat sich erledigt. Die beschriebene Vorgehensweise führte zu einer lauffähigen hddtemp und einer passenden libc. Danke noch mal für den Tipp.
FlashErase
Neugieriger
Neugieriger
Beiträge: 14
Registriert: Mittwoch 5. September 2007, 18:25

Beitrag von FlashErase »

Muß mich doch noch mal melden. Ganz so einfach scheint das doch nicht zu sein. Kann mir bitte noch mal jemand auf die Sprünge helfen? Zu welchem Zeitpunkt müssen die Binaries und Module in welchem Verzeichnis liegen, damit die benötigten Symbole nicht aus den Libs gestrippt werden. Spiele ich sie bereits mit der root-local.sh nach cdkflash/root/bin werden alle übrigen Binaries und Libs gar nicht erst in's Image (cdkflash/root-neutrino-squashfs/bin) eingespielt und das Image ist nicht lauffähig. Spiele ich sie mit root-squashfs-local.sh nach cdkflash/root-neutrino/bin werden die benötigten Symbole trotzdem aus den Libs gestrippt. Zum Beispiel der fritzboxcallmon. In cdkflash/root/bin verhindert er die Erzeugung der übrigen Binaries und in cdkflash/root-squashfs/bin oder cdkflash/root-neutrino/bin zeigt er keine Wirkung auf das Strippen.
Ich wäre Euch dankbar. wenn Ihr mir sagen könntet, mit welchem customize-Script ich die Binaries oder Module wohin schieben muß und ob es zu früh ist wenn ich diese eingespielten Dateien mit root-neutrino-squashfs-local.sh wieder entferne, damit sie nicht in's Image gepackt werden.
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Beitrag von seife »

Also ich kann nicht garantieren, daß das hilft, aber ich schiebe die Sachen im root-neutrino-local.sh nach $1/root-neutrino/lib/ und damit funktioniert es bei mir scheinbar. Ich habe aber auch nur eine triviallib (shell.so, aus dem yadi-Tarball), die vermutlich kaum andere symbole braucht.
Jedenfalls sind sie dann schon installiert, wenn mklibs.py aufgerufen wird.

Edit: Achtung, ich bin absoluter newmake-Anfänger, also Vorsicht :-)
FlashErase
Neugieriger
Neugieriger
Beiträge: 14
Registriert: Mittwoch 5. September 2007, 18:25

Beitrag von FlashErase »

Danke für den Tipp. Werde das mal an dieser Stelle versuchen. Kann man die zusätzlich eingespielten Dateien dann mit der root-neutrino-squashfs-local.sh wieder entfernen oder ist das zu früh? Ich habe noch nicht richtig mitbekommen, wann genau diese mklibs.py anspringt.
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Beitrag von seife »

Ja, soweit ich das sehe sollte das gehen.
Ich baue in meine customization-skripten immer ganz oben ein

Code: Alles auswählen

echo "running $0"
ein, dann sehe ich nachher im Log, was wann kam :-)
FlashErase
Neugieriger
Neugieriger
Beiträge: 14
Registriert: Mittwoch 5. September 2007, 18:25

Beitrag von FlashErase »

Hallo seife,

danke für Deine Tipps. Das war genau an der richtigen Stelle. Jetzt bleiben die benötigten Symbole in den Libs drin. Ich hatte zwar eine root-local, root-squashfs-local, root-neutrino-squashfs-local, var-neutrino-local aber eine root-neutrino-local hatte ich noch nicht. Und genau da gehörte das Kopieren der Binaries ja rein. Also vielen Dank noch mal.