Erstellt vor 7 Jahren

Geschlossen vor 7 Jahren

#1126 closed defect (fixed)

[openssl] Build fails: "Makefile is is older than Makefile.org, Configure or config."

Erstellt von: schlimmchen Verantwortlicher: oliver
Priorität: normal Meilenstein: freetz-1.2
Komponente: packages Version: devel
Stichworte: Beobachter:
Product Id: Firmware Version:

Beschreibung

The Freetz build fails with the following error message (in this case 7390):

cmd() { PATH="/home/schlimmchen/Documents/freetz/freetz-7390-trunk-schlimmchen/toolchain/build/mips_gcc-4.4.5_uClibc-0.9.29/mips-linux-uclibc/bin:/home/schlimmchen/Documents/freetz/freetz-7390-trunk-schlimmchen/toolchain/build/mips_gcc-3.4.6/mips-unknown-linux-gnu/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games" LD_RUN_PATH="/usr/lib/freetz" make -j2  "$@"  || { printf "\n\\033[33m%s\\033[m\n" "ERROR: Build failed.";  exit 1; } }; 	if [ -e source/.echo_item_start -a ! -e source/.echo_item_build ]; then echo -n "building... "; touch source/.echo_item_build; fi; cmd -C source/target-mips_uClibc-0.9.29/openssl-0.9.8q \
		SHARED_LDFLAGS="" \
		CC="/home/schlimmchen/Documents/freetz/freetz-7390-trunk-schlimmchen/toolchain/build/mips_gcc-4.4.5_uClibc-0.9.29/mips-linux-uclibc/bin/mips-linux-uclibc-gcc" \
		AR="/home/schlimmchen/Documents/freetz/freetz-7390-trunk-schlimmchen/toolchain/build/mips_gcc-4.4.5_uClibc-0.9.29/mips-linux-uclibc/bin/mips-linux-uclibc-ar r" \
		RANLIB="/home/schlimmchen/Documents/freetz/freetz-7390-trunk-schlimmchen/toolchain/build/mips_gcc-4.4.5_uClibc-0.9.29/mips-linux-uclibc/bin/mips-linux-uclibc-ranlib" \
		all
make[1]: Entering directory `/home/schlimmchen/Documents/freetz/freetz-7390-trunk-schlimmchen/source/target-mips_uClibc-0.9.29/openssl-0.9.8q'
Makefile is older than Makefile.org, Configure or config.
Reconfigure the source tree (via './config' or 'perl Configure'), please.
make[1]: *** [Makefile] Error 1
make[1]: Leaving directory `/home/schlimmchen/Documents/freetz/freetz-7390-trunk-schlimmchen/source/target-mips_uClibc-0.9.29/openssl-0.9.8q'

ERROR: Build failed.
make: *** [source/target-mips_uClibc-0.9.29/openssl-0.9.8q/libssl.so.0.9.8] Error 1

Steps to reproduce:

  • checkout untouched trunk
  • make menuconfig (might need attached .config to reproduce)
  • make

OR (assuming openssl package is selected):

  • rm -r source/target-mipsel_uClibc-0.9.29/openssl-0.9.8q/

Dirty Workaround:

touch source/target-mips_uClibc-0.9.29/openssl-0.9.8q/Makefile

Since revision: unknown. I guess r6304.

The same problem occurs with 7270, slightly different folder names though.

Environment:

  • Ubuntu 10.10 x86_64 (real machine)

Anhänge (1)

.config (27.4 KB) - hinzugefügt von schlimmchen vor 7 Jahren.

Alle Anhänge herunterladen als: .zip

Änderungshistorie (9)

Geändert vor 7 Jahren durch schlimmchen

comment:1 Geändert vor 7 Jahren durch oliver

Ich kann das Problem nicht nachvollziehen. Allerdings wurde es schon öfter mal erwähnt, z.B. hier und hier. Vielleicht kannst du mal die Hinweise von Ralf probieren.

Welche Datei hat denn den falschen Timestamp?

Zuletzt geändert vor 7 Jahren von oliver (vorher) (Diff)

comment:2 Geändert vor 7 Jahren durch er13

comment:3 Antwort: Geändert vor 7 Jahren durch schlimmchen

Seltsam, dass ich die zwei Threads mit google so schnell nicht gefunden hab.

$ ls --full-time -al source/target-mips_uClibc-0.9.29/openssl-0.9.8q/ |grep -E 'Make|[C|c]onfig'
-rwxr-xr-x  1 schlimmchen schlimmchen  25909 2010-03-09 18:08:24.000000000 +0100 config
lrwxrwxrwx  1 schlimmchen schlimmchen      9 2010-12-21 13:09:26.575050346 +0100 configure -> Configure
-rwxr-xr-x  1 schlimmchen schlimmchen  95183 2010-12-21 13:09:26.575050346 +0100 Configure
-rw-r--r--  1 schlimmchen schlimmchen      0 2010-12-21 13:09:26.635051018 +0100 .configured
-rw-r--r--  1 schlimmchen schlimmchen  26456 2010-12-21 13:09:26.000000000 +0100 Makefile
-rw-r--r--  1 schlimmchen schlimmchen  25262 2010-12-21 13:09:26.355047884 +0100 Makefile.bak
-rw-r--r--  1 schlimmchen schlimmchen  24827 2010-12-21 13:09:26.365047996 +0100 Makefile.org
-rw-r--r--  1 schlimmchen schlimmchen  20257 2008-09-17 17:56:40.000000000 +0200 Makefile.shared

Wo ich mir diese Auflistung so ansehe, wird wohl schnell deutlich, dass irgendwer die Nanosekunden der Makefile verschlampt. Ich behaupte, auf langsameren Systemen passiert das nicht, weil dann mindestens eine Sekunde vergeht, bevor die Makefile erstellt/verändert wird. (?)

Eben hat es einmal zufällig geklappt, wohl weil ich "im Umbruch einer Sekunde" losgelegt habe.

Vonwegen Dateisystem (war Thema in einem der oben verlinkten Threads): Ich setze ext4 ein auf einer SSD. Beides ist für mich neu (hab ich vorher nie eingesetzt). Mag sein, dass das den Fehler begünstigt, genaues weiß ich aber nicht.

Die zlib1g-dev (von sheepy erwähnt) hab ich schon installiert.

Anstatt des Patches könnte man natürlich auch sowas machen:

  • make/libs/openssl.mk

     
    3232$(PKG_CONFIGURED_CONFIGURE) 
    3333 
    3434$($(PKG)_SSL_BINARY) $($(PKG)_CRYPTO_BINARY): $($(PKG)_DIR)/.configured 
     35    @touch $(OPENSSL_DIR)/Makefile 
    3536    $(SUBMAKE) -C $(OPENSSL_DIR) \ 
    3637        SHARED_LDFLAGS="" \ 
    3738        CC="$(TARGET_CC)" \ 

Was haben sich denn die openssl Leute gedacht? Wollen sie sicherstellen, dass die Makefile auch bearbeitet wurde vom ./configure?

comment:4 als Antwort auf: ↑ 3 ; Antwort: Geändert vor 7 Jahren durch ralf

EXT4 speichert aber auch die Sekundenbruchteile. Woher kommt also diese glatte Zeit bei Makefile?

comment:5 als Antwort auf: ↑ 4 ; Antwort: Geändert vor 7 Jahren durch schlimmchen

Replying to ralf:

EXT4 speichert aber auch die Sekundenbruchteile.

Ich weiß, das geht ja auch aus aus meinem ls hervor.

Woher kommt also diese glatte Zeit bei Makefile?

Aus dem Archiv. Sie wird vermutlich nur nicht richtig aktualisiert, die Nanosekunden werden wohl eher nicht ausdrücklich auf 0 gesetzt.

Ich hab diesen Abschnitt im make (3.81/3.82) README gefunden:

On systems that support micro- and nano-second timestamp values and
where stat(2) provides this information, GNU make will use it when
comparing timestamps to get the most accurate possible result.  However,
note that many current implementations of tools that *set* timestamps do
not preserve micro- or nano-second granularity.  This means that "cp -p"
and other similar tools (tar, etc.) may not exactly duplicate timestamps
with micro- and nano-second granularity on some systems.  If your build
system contains rules that depend on proper behavior of tools like "cp
-p", you should consider using the .LOW_RESOLUTION_TIME pseudo-target to
force make to treat them properly.  See the manual for details.

Kennt jemand dieses Target? Können wir das reinpatchen?

comment:6 als Antwort auf: ↑ 5 Geändert vor 7 Jahren durch ralf

Replying to schlimmchen:

Ich weiß, das geht ja auch aus aus meinem ls hervor.

Ich habe früher schon mal gesehen, daß im Cache eine Zeit mit Nano-Sekunden war, die aber vom Dateisystem auf der Platte nicht gespeichert werden konnte. Die Nano-Sekunden wurden also angezeigt, bis die Datei aus dem Cache verdrängt wurde und wieder von der PLatte nachgeladen werden mußte.
Anscheinend ist das aber mit meinen aktuelleren Kernel-Versionen nicht mehr so.

Woher kommt also diese glatte Zeit bei Makefile?

Aus dem Archiv. Sie wird vermutlich nur nicht richtig aktualisiert, die Nanosekunden werden wohl eher nicht ausdrücklich auf 0 gesetzt.

Sie kommt nicht aus dem Archiv, weil es das aktuelle Datum/Zeit ist und nicht älter wie die Datei config oben im Beispiel. Mein cp Programm kopiert auch die Nano-Sekunden einer Datei.

Kennt jemand dieses Target? Können wir das reinpatchen?

Das könnte gehen. Du kannst die Datei zunächst von Hand ändern. Wenn es damit geht, kannst DU einen Patch erstellen.

comment:7 Geändert vor 7 Jahren durch cuma

  • Meilenstein von freetz-1.1.4 nach freetz-1.2 geändert

comment:8 Geändert vor 7 Jahren durch oliver

  • Lösung auf fixed gesetzt
  • Status von new nach closed geändert
  • Verantwortlicher auf oliver gesetzt

In [6368]:

  • openssl: Add patch from openwrt (removes timestamp check from Makefile)
Hinweis: Hilfe zur Verwendung von Tickets finden Sie in TracTickets.