[gelöst] freetz-devel-5242: make[1]: *** [libz.so.1.2.5] Fehler 1

[ao]

EDIT: Problem gelöst mit Changeset 5279.
_____

Hallo,

ich habe den Trunk (5242) frisch ausgecheckt, aber beim Bau kommt dies:

BITS=64 -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64 -c -o example64.o example.c
/home/user/freetz/7170/toolchain/target/bin/mipsel-linux-uclibc-gcc -Os -pipe -march=4kc -Wa,--trap -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64 -c -o minigzip64.o minigzip.c
/home/user/freetz/7170/toolchain/target/bin/mipsel-linux-uclibc-ar rc libz.a adler32.o compress.o crc32.o deflate.o gzclose.o gzlib.o gzread.o gzwrite.o infback.o inffast.o inflate.o inftrees.o trees.o uncompr.o zutil.o 
/home/user/freetz/7170/toolchain/target/bin/mipsel-linux-uclibc-gcc -shared -Wl,-soname,libz.so.1,--version-script,zlib.map -Os -pipe -march=4kc -Wa,--trap -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC -D_LARGEFILE64_SOURCE=1 -o libz.so.1.2.5 adler32.lo compress.lo crc32.lo deflate.lo gzclose.lo gzlib.lo gzread.lo gzwrite.lo infback.lo inffast.lo inflate.lo inftrees.lo trees.lo uncompr.lo zutil.lo  -lc -L. libz.a
mipsel-linux-uclibc-gcc: libz.a: No such file or directory
make[1]: *** [libz.so.1.2.5] Fehler 1
make[1]: *** Warte auf noch nicht beendete Prozesse...
make[1]: Verlasse Verzeichnis '/home/user/freetz/7170/source/target-mipsel_uClibc-0.9.29/zlib-1.2.5'

ERROR: Build failed.
make: *** [source/target-mipsel_uClibc-0.9.29/zlib-1.2.5/libz.so.1.2.5] Fehler 1

Das Problem mit libz hatte ich nun schon mehrmals. Any good ideas?

 

[sf3978]

Versuch mal:

rm source/target-mipsel_uClibc-0.9.29/config.cache

make zlib-dirclean

make zlib-precompiled

 

[ao]

Vielen Dank für die schnelle Hilfe!
Seltsamerweise scheint der "make"-Vorgang nach nochmaligem Aufruf (ca. 1h später) korrekt durchzulaufen (ohne "svn up" o.ä.).

Changeset 5244 scheint das Problem nun zu lösen. Danke dafür an Oliver!
EDIT (s.u.): Nein, es scheint damit nichts zu tun zu haben.

 

[sf3978]

[...]
Seltsamerweise scheint der "make"-Vorgang nach nochmaligem Aufruf (ca. 1h später) korrekt durchzulaufen (ohne "svn up" o.ä.).
[...]

Und auch ohne:

rm source/target-mipsel_uClibc-0.9.29/config.cache

?

 

[ao]

Ich habe nach meinem 1. Post oben 1h lang etwas anderes gemacht und dann einfach noch einmal "make" ausgeführt (kein rm..., dirclean).
Mehr nicht. Und damit ging es (5242).

EDIT:
Eben habe ich ein "svn up" (auf 5244) gemacht, dann wie von Dir oben vorgeschlagen:

rm source/target-mipsel_uClibc-0.9.29/config.cache
make zlib-dirclean
make zlib-precompiled

Beim letzten (precompiled) kam dann aber wieder der Fehler:

/home/user/freetz/7170/toolchain/target/bin/mipsel-linux-uclibc-gcc  -shared -Wl,-soname,libz.so.1,--version-script,zlib.map -Os -pipe  -march=4kc -Wa,--trap -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE  -D_FILE_OFFSET_BITS=64 -fPIC -D_LARGEFILE64_SOURCE=1 -o libz.so.1.2.5  adler32.lo compress.lo crc32.lo deflate.lo gzclose.lo gzlib.lo gzread.lo  gzwrite.lo infback.lo inffast.lo inflate.lo inftrees.lo trees.lo  uncompr.lo zutil.lo  -lc -L. libz.a
mipsel-linux-uclibc-gcc: libz.a: No such file or directory
make[1]: *** [libz.so.1.2.5] Fehler 1[COLOR=Red]
make[1]: *** Warte auf noch nicht beendete Prozesse...[/COLOR]
make[1]: Verlasse Verzeichnis  '/home/user/freetz/7170/source/target-mipsel_uClibc-0.9.29/zlib-1.2.5'

ERROR: Build failed.
make: *** [source/target-mipsel_uClibc-0.9.29/zlib-1.2.5/libz.so.1.2.5]  Fehler 1

Da scheint der Wurm drin zu sein ("Warte auf noch nicht beendete Prozesse...").

Mein "dl" Verzeichnis liegt eine Ebene höher, mit einem Softlink hin, so dass ich nicht immer alles neu runterladen muss.
Veraltete Komponenten lösche ich immer mal wieder manuell. Das sollte also kein Problem sein.

Erstaunlich ist, dass ich in "dl" ein uclibc mit seltsamem Namen finde:

-rw-r--r-- 1 user users 257792 2010-07-11 12:15 [COLOR=Red]uClibc++-5976d7536d8c7a8d5a7f60fd2a3c34876a224f30.tar.bz2[/COLOR]

Das ist doch kein normaler Dateiname für eine Freetz-Komponente. Die Datei lösche ich vorsichtshalber mal - wird ja dann neu geladen.

Tja, genau die Datei wird nach nach einem neuen "make" wieder geladen:

user@ubuntu-vm:~/freetz/7170$ make
if [ ! -e source/.echo_item_start ]; then       echo -n "---> "; case "LIB" in BIN)     echo -n "package/uclibcxx: " ;; LIB)    echo -n "library/uclibcxx: " ;; TOOL)        echo -n "tool/uclibcxx: " ;; *) echo -n "kernel: " ;; esac; rm -f source/.echo_item_build; touch source/.echo_item_start; fi; echo -n "downloading... ";
downloading... 
--19:47:47--  http://git.uclibc.org/uClibc++/snapshot/[COLOR=Red]uClibc++-5976d7536d8c7a8d5a7f60fd2a3c34876a224f30.tar.bz2[/COLOR]

Immerhin läuft "make" damit anscheinend fehlerfrei durch. Aber ich traue dem nicht...
Ich mache wohl mal lieber einen ganz frischen Checkout in ein neues Verzeichnis (auf 5244) und sehe dann weiter.

 

[er13]

rm source/target-mipsel_uClibc-0.9.29/config.cache

libz nutzt kein config.cache (wegen $(PKG)_CONFIGURE_DEFOPTS := n), d.h. das Löschen von diesem würde nichts bringen. Genauso wenig dürfte auch r5244 helfen (hat rein gar nichts mit dem Problem zu tun)

uClibc++-5976d7536d8c7a8d5a7f60fd2a3c34876a224f30.tar.bz2
Das ist doch kein normaler Dateiname für eine Freetz-Komponente.

doch, es ist ein git-snapshot und diese werden nun mal so nummeriert...

Ich mache wohl mal lieber einen ganz frischen checkout auf die 5244 und sehe dann weiter.

Mach lieber

make zlib-dirclean
make zlib-precompiled 2>&1 | tee zlib.log

und hänge zlib.log hier an... Du kannst auch versuchen in der .mk-Datei SUBMAKE durch SUBMAKE1 zu ersetzen

 

[ao]

Hallo und herzlichen Dank für die hilfreiche Erklärung und den Trick mit dem Logging - sehr praktisch.
Das Logfile habe ich angehängt (dirclean habe ich vorher auch gemacht, wie von Dir beschrieben).
Dann habe ich "make zlib-precompiled 2>&1 | tee zlib.log"einfach noch einmal aufgerufen (zlib2.log) - siehe Anhang.
Damit läuft es ohne Fehler durch. Was ist da los?

Sind denn die Logfile so überhaupt ok? Ich habe das Gefühl, dass da etwas fehlt, vor allem beim 2. Mal.
Aber vielleicht liegt das daran, dass es vorher ja schon aufgerufen worden war und ich beim 2. Mal kein dirclean gemacht habe.
Aber was sagt uns das nun?
Es wird wohl libz.a nicht gefunden (siehe 1. Log). Warum auch immer?

Ich hoffe, dass das Logfile weiterhilft. Gerne liefere ich noch weitere Infos nach.
.

 

[er13]

sieht stark nach demselben Problem wie im Ticket 842 aus, wobei komisch ist, dass es bisher niemandem aufgefallen ist. Wie gesagt ersetze mal SUBMAKE durch SUBMAKE1 in zlib.mk, mach ein make zlib-dirclean, und dann ein erneutes make zlib-precompiled und berichte uns, ob es gleich beim ersten mal mit dem Übersetzen klappt.

 

[olistudent]

Könnte es mit dem ranlib Befehl im zlib Makefile zu tun haben?

libz.a: $(OBJS)
        $(AR) $@ $(OBJS)
        -@ ($(RANLIB) $@ || true) >/dev/null 2>&1

Ich hab kein Problem beim Bauen.

MfG Oliver

 

[RalfFriedl]

Das sieht aus, als würde eine Abhängigkeit im Makefile fehlen, was ein Fehler in zlib wäre.

Allerdings ist der Fehler bei mir nicht aufgetreten, und ich verwenden FREETZ_JLEVEL=16, hauptsächlich um solche fehlenden Abhängigkeiten zu bemerken.

Tatsächlich ist der Fehler im Makefile von zlib, ich haben dafür einen Patch in der neuesten Trunk-Version gemacht. Schau mal, ob das den Fehler beseitigt.

--- Makefile.in~        2010-04-20 06:12:21.000000000 +0200
+++ Makefile.in 2010-07-11 21:43:48.000000000 +0200
@@ -137,7 +137,7 @@
        -@mv objs/$*.o $@

 $(SHAREDLIBV): $(PIC_OBJS)
-       $(LDSHARED) $(SFLAGS) -o $@ $(PIC_OBJS) $(LDSHAREDLIBC) $(LDFLAGS)
+       $(LDSHARED) $(SFLAGS) -o $@ $(PIC_OBJS) $(LDSHAREDLIBC)
        rm -f $(SHAREDLIB) $(SHAREDLIBM)
        ln -s $@ $(SHAREDLIB)
        ln -s $@ $(SHAREDLIBM)

 

[er13]

Dein Fix gefällt mir nicht ganz, der korrekte sollte eher so aussehen (beides ungetestet, da unter Windows):

--- configure
+++ configure
@@ -19,7 +19,6 @@
 fi
 
 STATICLIB=libz.a
-LDFLAGS="${LDFLAGS} -L. ${STATICLIB}"
 VER=`sed -n -e '/VERSION "/s/.*"\(.*\)".*/\1/p' < zlib.h`
 VER3=`sed -n -e '/VERSION "/s/.*"\([0-9]*\\.[0-9]*\\.[0-9]*\).*/\1/p' < zlib.h`
 VER2=`sed -n -e '/VERSION "/s/.*"\([0-9]*\\.[0-9]*\)\\..*/\1/p' < zlib.h`

 

[RalfFriedl]

Das Ergebnis sollte das Gleiche sein, da LDFLAGS sonst nirgends verwendet wird.

Prinzipiell ist es richtig, daß LDFLAGS nicht dazu gedacht ist, Libraries mit anzugeben.

Ich hoffe aber, daß in der nächsten Version der Fehler korrigiert ist und es gar keinen Patch mehr braucht.

 

[ao]

ich verwenden FREETZ_JLEVEL=16, hauptsächlich um solche fehlenden Abhängigkeiten zu bemerken.

Hallo Ralf, könntest Du das bitte mit ein paar Worten näher erläutern? Danke!
Zum Testen komme ich erst später, melde mich dann aber gerne noch einmal.
Und danke an alle für's Patchen!

 

[RalfFriedl]

Es gibt im Menuconfig eine Einstellung dafür, Standard ist 2. Ich habe eben 16 eingetragen.
Oder wolltest Du eine Erläuterung, wieso man damit normalerweise eher über Probleme stolpert?

 

[ao]

Nein, ich war daran interessiert, was dieser Schalter und der Wert 16 bewirkt.

EDIT:
Das ist ja "Number of jobs to run simultaneously"! Du lässt also beim "make" 16 Jobs parallel bauen?
Ich verstehe nicht, wie das geht. Hast Du einen Quad Core-Rechner o.ä.?
Und weshalb ist das zum Fehlerfinden vorteilhaft?

 

[RalfFriedl]

Nein, ich habe keinen Quad-Core. Es geht auch nicht darum, ob es auf die Art schneller ist. Solange man genug Speicher hat, ist es aber auch nicht langsamer.

Manche Makefiles enthalten nicht alle Abhängigkeiten, funktionieren aber trotzdem, wenn alle Regeln eine nach der anderen bearbeitet werden. Wenn jetzt aber Regeln parallel abgearbeitet werden, dann kann es passieren, daß make schon einen Aufruf startet, obwohl eine benötigte Datei noch nicht erstellt wurde, aber das Makefile nicht aussagt, daß die Datei benötigt wird. Dann wird schon mal MAKE1 statt MAKE empfohlen, damit immer nur ein Job nach dem anderen ausgeführt wird. Das hilft zwar, ist aber nicht die beste Lösung. Besser ist es, den Fehler im Makefile zu korrigieren.

Theoretisch sollte so ein Fehler umso eher auftreten, je höher die Anzahl der Jobs ist. In diesem Fall ist der Fehler aber bei mir nicht aufgetreten. Es können aber noch verschiedene andere Faktoren einen Einfluß haben.

 

[ao]

Dein Fix gefällt mir nicht ganz, der korrekte sollte eher so aussehen (beides ungetestet, da unter Windows): ...

Hallo, wurde das inzwischen in freetz-devel eingebaut? (sorry, falls ich es übersehen habe)

 

[olistudent]

Hast du bestätigt, dass der Patch von er13 dein Problem löst?

Mfg Oliver

 

[ao]

Hallo Oliver, wie folgt ging es dann:

sieht stark nach demselben Problem wie im Ticket 842 aus, wobei komisch ist, dass es bisher niemandem aufgefallen ist. Wie gesagt ersetze mal SUBMAKE durch SUBMAKE1 in zlib.mk, mach ein make zlib-dirclean, und dann ein erneutes make zlib-precompiled und berichte uns, ob es gleich beim ersten mal mit dem Übersetzen klappt.

Logs hatte ich oben angehängt.

 

[olistudent]

Das war aber nur ein Workaround. Der Patch aus #11 ist der eigentliche Fix.

MfG Oliver