Freetz-Trunk: "root/user/lib" existiert nicht (Problem seit changeset 3209)

[ao]

Hallo,

beim Kompilieren (Freetz-3243 für FB 7170; kein Labor) meckert "make", dass das Verzeichnis "root/user/lib" nicht existiert.

[EDIT:
Wie Oliver weiter unten im Thread schreibt, sei das Problem auch eine Folge von changeset 3209 ("Also remove packages directory if SUBOPTS are changed").
Ein revert von r3209 könne das Problem lösen.]

Ich nutze "replace kernel" und ein SquashFS mit 128 KB block size. Anbei ein Auszug aus dem Output beim 'make':

...
make[1]: Verlasse Verzeichnis '/home/m740/freetz-trunk/source/neon-0.28.3'
sed -i -r -e "s,^libdir=('?)(.*)('?)$,libdir=\1/home/m740/freetz-trunk/toolchain/build/gcc-4.2.1-uClibc-0.9.29/mipsel-linux-uclibc\2\3,g" -e "s,^includedir=('?)(.*)('?)$,includedir=\1/home/m740/freetz-trunk/toolchain/build/gcc-4.2.1-uClibc-0.9.29/mipsel-linux-uclibc\2\3,g" -e "s,^prefix=('?)(.*)('?)$,prefix=\1/home/m740/freetz-trunk/toolchain/build/gcc-4.2.1-uClibc-0.9.29/mipsel-linux-uclibc\2\3,g" -e "s,^exec_prefix=('?)(.*)('?)$,exec_prefix=\1/home/m740/freetz-trunk/toolchain/build/gcc-4.2.1-uClibc-0.9.29/mipsel-linux-uclibc\2\3,g" \
        /home/m740/freetz-trunk/toolchain/build/gcc-4.2.1-uClibc-0.9.29/mipsel-linux-uclibc/lib/libneon.la \
        /home/m740/freetz-trunk/toolchain/build/gcc-4.2.1-uClibc-0.9.29/mipsel-linux-uclibc/lib/pkgconfig/neon.pc \
        /home/m740/freetz-trunk/toolchain/build/gcc-4.2.1-uClibc-0.9.29/mipsel-linux-uclibc/bin/neon-config
cp -a /home/m740/freetz-trunk/toolchain/build/gcc-4.2.1-uClibc-0.9.29/mipsel-linux-uclibc/usr/lib/libneon*.so* root/usr/lib/
[COLOR=Red] cp: angegebenes Ziel „root/usr/lib/“ ist kein Verzeichnis[/COLOR]
[COLOR=Red] make: *** [root/usr/lib/libneon.so.27.1.3] Fehler 1[/COLOR]

 

[olistudent]

Hi.
Ich nehme an, dass du ein "make dirclean" vorher gemacht hattest? Welche Pakete hast du denn an? Evtl. löscht eins davon root/usr/lib. Das sollte nicht passieren, weil da noch 2 andere wichtige Dateien drin sind.

MfG Oliver

 

[ao]

Hallo Oliver,

vorher hatte ich sowohl ein distclean als auch ein dirclean gemacht. Meine Konfig. habe ich angehängt.
Ich entferne nun solange Pakete, bis es geht. Damit sollte ich es herausfinden...

 

[olistudent]

Hab das Problem. Ist auch eine Folge von r3209.

MfG Oliver

 

[ao]

Was genau meinst Du damit?
Ich habe mir das Changeset 3209 [EDIT: Link korrigiert] angeschaut, aber das geht es nur um tor, was ich noch nieverwendet habe.

Bevor ich jetzt weitere Pakete rausnehme und ständig neu kompiliere, wäre es nett, wenn Du noch ein paar Hinweise geben könntest. Vielen Dank!

 

[olistudent]

Du hast dir Changeset 3203 angeschaut. ;-)

MfG Oliver

 

[ao]

Sorry, danke für den Hinweis, aber leider habe ich es immer noch nicht verstanden.

Was bedeutet denn "Also remove packages directory if SUBOPTS are changed"? (sorry, den Code verstehe ich nicht)
Was sind "subopts", und wie verhalte ich mich, damit ich nicht in dieses Problem renne?

Ich hatte auch noch nach 3209 etliche FWs gebaut, ohne dabei das o.g. Problem zu bekommen.
Es liegt doch sicherlich nur an einem oder zwei Paketen bzw. an einem bestimmten Verhalten.

Könntest Du das mir Linux-DAU bitte kurz erläutern? Danke!

PS:
Wird es einen Fix geben bzw. gibt es bis dahin einen Workaround?
Hat Changeset 3244 etwas mit einem Fix zu tun? Da steht zumindest, dass für netsnmp ein Lib-Verzeichnis erstellt wird.
Aber ich kann mir andererseits nicht erinnern, netsnmp zu nutzen:

# FREETZ_PACKAGE_NETSNMP is not set

 

[olistudent]

Der Workaround wäre r3209 zu reverten. Wird derzeit nur für e2fsprogs benötigt. Evtl. könntest du den Thread Titel auch umbenennen.

MfG Oliver

 

[ao]

Heisst das, dass man das Problem gar nicht hat, wenn man e2fsprogs nicht mit auswählt, oder wäre das Problem nur behoben, wenn man den r3209 komplett reverted - also egal, ob jemand e2fsprogs nutzen will oder nicht? Den Thread-Titel habe ich angepasst.

 

[olistudent]

Das Problem ist nur behoben, wenn du r3209 revertest. (steht oben schonmal ;-) )

MfG Oliver

 

[RalfFriedl]

Es hat auch nichts damit zu tun, ob Du e2fsprogs ausgewählt hast oder nicht.

Die Änderung wurde gemacht, um die Unteroptionen von e2fsprogs zu unterstützen, aber sie wirkt sich grundsätzlich aus.

Was das Revert betrifft, entweder schaust Du im Manual von svn nach, oder Du schaust Dir die Änderung an und machst sie von Hand rückgängig.

 

[ao]

Sorry, Ralf, meinen Post zwischen Olivers und Deinem hatte ich eben gelöscht, weil ich ihn im Nachhinein blöd fand.

Nachdem ich nun doch noch einen ganz frischen Anlauf ("rm -Rf freetz-trunk" und nochmal von ganz vorn) versucht habe, trat das Problem auch mit dem aktuellsten (derzeit r3251) Freetz-Trunk auf, auch mit einer abgespeckten Auswahl an Paketen. Aber ich habe noch nicht herausgefunden, wann genau es auftritt, da es manchmal eben auch nicht auftritt.

Habe ich Dich richtig verstanden, dass gewisse Pakete, die eine Unterauswahl anbieten (nicht nur e2fsprogs), das Problem hervorrufen, oder nur e2fsprogs (aber egal, ob genutzt oder nicht)?

PS: .config im Anhang (falls es jemandem hilft).
.

 

[RalfFriedl]

Es könnte sogar sein, daß es alle Pakete betrifft, unabhängig von der Unterauswahl (SUBOPTS). Du könntest mal die rm-Befehle durch "exit 1" ersetzen, dann sollte make an der Stelle stehen bleiben, vielleicht gibt das einen Hinweis darauf, bei welchem Paket das ausgeführt wird.

 

[olistudent]

Das Target wird bei allen Packages mit SUBOPTS ausgeführt. Unter anderem auch für neon, von deinem ersten Post.

MfG Oliver

 

[ao]

Ok, danke für den Hinweis! Hätte ich ja oben im Output auch herauslesen können, wenn ich nicht so unbedarft wäre.
Nun habe ich in der Tat auch verifizieren können, dass der Fehler nicht auftritt, wenn ich WebDAV (siehe svn) bzw. davfs (libneon) weglasse.
Sobald ich davfs wähle (auch ohne SSL und ohne zlib Support), bricht make wieder ab, da "root/usr/lib/“ gelöscht wurde.

EDIT1:
Es wundert mich allerdings, dass der FW-Bau zwischendurch mit anderen Trunk-Versionen (z.B. r3185) auch mit davfs (inkl. ssl+zlib) geklappt hatte.
Und jetzt auch mit r3251 - siehe .config im Anhang. Es muss also an einer Wechselwirkung zwischen davfs und noch irgend etwas anderem liegen.

EDIT2:
Danach habe ich (ohne make dirclean) noch einmal make menuconfig aufgerufen, und bei davfs zusätzlich noch SSL- und zlib-Support ausgewählt.
Und siehe da: /root/usr/lib wurde gelöscht! Ich verstehe nicht, was ssl und zlib damit zu tun haben.

Anbei auch noch das diff zwischen davfs ohne SSL- und zlib-Support und mit beidem (wobei es wie geschrieben erst mit beidem zum Löschen von "/root/usr/lib kam"):

$ diff config_mit_davfs.txt config_mit_davfs_mit_ssl_und_zlib.txt 
185,186c185,186
< # FREETZ_DAVFS2_WITH_SSL is not set
< # FREETZ_DAVFS2_WITH_ZLIB is not set
---
> FREETZ_DAVFS2_WITH_SSL=y
> FREETZ_DAVFS2_WITH_ZLIB=y
444,445c444,446
< # FREETZ_LIB_libcrypto is not set
< # FREETZ_LIB_libssl is not set
---
> FREETZ_LIB_libcrypto=y
> FREETZ_LIB_libssl=y
> # FREETZ_LIB_libavmhmac is not set
451c452
< # FREETZ_LIB_libz is not set
---
> FREETZ_LIB_libz=y
511,512c512,513
< # FREETZ_LIB_libneon_WITH_SSL is not set
< # FREETZ_LIB_libneon_WITH_ZLIB is not set
---
> FREETZ_LIB_libneon_WITH_SSL=y
> FREETZ_LIB_libneon_WITH_ZLIB=y

Sofern Dir, Oliver (oder auch anderen) dieses Problem noch klarer geworden ist und sich auch ein passenderer Thread-Titel empfiehlt, bitte ich um Rückmeldung.
Gerne teste ich noch weiter, sofern es mit meinen bescheidenen Kenntnissen möglich ist.

EDIT3:
Zuvor hatte ich testhaber /root/usr/lib komplett gesichert und nach der Löschung durch davfs+ssl+zlib beim make anschließend wieder zurückgespielt und noch einmal make aufgerufen. So konnte die FW doch gebaut werden.
Danach habe ich gleich noch einmal make aufgerufen:

$ make
mkdir -p packages/davfs2-1.3.3/root
if test -d make/davfs2/files; then tar -c -C make/davfs2/files --exclude=.svn . | tar -x -C packages/davfs2-1.3.3 ; fi
STEP 1: UNPACK
unpacking firmware image
splitting kernel image
unpacking filesystem image
  3850 inodes (4005 blocks) to write
  created 3401 files
  created 158 directories
  created 292 symlinks
  created 157 devices
  created 0 fifos
unpacking var.tar
done.

STEP 2: MODIFY
...

Auch der Bau war erfolgreich, d.h. dass beim 2. make das Verzeichnis /root/usr/lib offenbar nicht mehr gelöscht wurde. Kapiere ich nicht...
.

 

[ao]

Ich schreibe mal einen neuen Beitrag, weil der oben sonst zu unübersichtlich wird, vor allem wegen der Anhänge.

Hier nun meine .configs, mit denen der FW-Bau in der Reihenfolge für die 7170 bisher problemlos geklappt hat, d.h. keine Löschung von /root/usr/lib.
Das nur mal so als Zwischenstand...

EDIT1: Anhang noch einmal upgedatet - es geht immer noch...
EDIT2: Noch mehr Durchläufe (configs im Anhang) - und es geht immer noch.

Momentan kann ich das in diesem Thread beschriebene Problem nicht mehr reproduzieren.

EDIT3: Da ich das Problem nicht wieder reproduzieren konnte, beende ich meine Bemühungen diesbzgl. Offenbar ist die Ursache des Problems ja einigermaßen bekannt, und evtl. wird es einen Fix geben.

Frohe stern!
.