Erstellt vor 9 Jahren

Zuletzt geändert vor 6 Jahren

#691 new addition

reiserfsprogs package

Erstellt von: HAL 9000 Verantwortlicher:
Priorität: low Meilenstein: freetz-future
Komponente: packages Version: devel
Stichworte: reiserfs reiserfsprogs reiserfstools Beobachter:
Product Id: Firmware Version:

Beschreibung

Ein binary only-paket für reiserfsprogs, analog zu e2fsprogs.

Anhänge (4)

reiserfsprogs.patch (6.9 KB) - hinzugefügt von HAL 9000 vor 9 Jahren.
reiserfsprogs_fixed_staging_dir.diff (6.8 KB) - hinzugefügt von HAL 9000 vor 9 Jahren.
reiserfsprogs_build_dir.patch (6.8 KB) - hinzugefügt von HAL 9000 vor 9 Jahren.
reiserfsprogs_fixed_makefile.patch (8.1 KB) - hinzugefügt von er13 vor 9 Jahren.
lässt sich nur mit selbstgebauter uClibc übersetzen

Alle Anhänge herunterladen als: .zip

Änderungshistorie (23)

comment:1 Geändert vor 9 Jahren durch oliver

Wow. Mit static pattern rules… ;-)

Geändert vor 9 Jahren durch HAL 9000

comment:2 Geändert vor 9 Jahren durch HAL 9000

Irgendwann muss ichs ja mal lernen ;)
Hab grad nochmal den Patch aktualisiert, da war noch eine Zeile aus einer früheren Version übrig geblieben.

comment:3 Antwort: Geändert vor 9 Jahren durch oliver

Gibt es einen Grund warum du die Binaries in die Toolchain installierst? Das ist bei subversion nur eine Ausnahme, weil wir die Libs brauchen und andere Programme dagegen linken.

comment:4 Antwort: Geändert vor 9 Jahren durch HAL 9000

Von subversion hab ichs. Das Problem ist, dass jedes Binary von reiserfsprogs in einem eigenen Verzeichnis gebaut wird, dieses Verzeichnis aber nicht immer genauso heißt wie das Binary. Ich wusste nicht wie ich das anders machen sollte, wenn du da einen Tipp hättest…

Geändert vor 9 Jahren durch HAL 9000

comment:5 Geändert vor 9 Jahren durch HAL 9000

Neuer Patch… ich glaub ich hab da eben den Wald vor lauter Bäumen nicht gesehen.

comment:6 als Antwort auf: ↑ 4 ; Antwort: Geändert vor 9 Jahren durch er13

Replying to HAL 9000:

Das Problem ist, dass jedes Binary von reiserfsprogs in einem eigenen Verzeichnis gebaut wird, dieses Verzeichnis aber nicht immer genauso heißt wie das Binary.

Wenn das so ist, dann ist $(PKG)_BINARIES_BUILD_DIR falsch definiert und das ganze nur deswegen funktioniert, weil eins der Binaries in $(PKG)_DIR) liegt. Schaue Dir, wie es in den Makefiles von bluez-utils und quagga gelöst ist.

comment:7 als Antwort auf: ↑ 3 Geändert vor 9 Jahren durch er13

Replying to oliver:

Das ist bei subversion nur eine Ausnahme, weil wir die Libs brauchen und andere Programme dagegen linken.

Kleine Anmerkung, es gibt Programme, die dagegen linken, diese sind aber nicht in freetz. Von daher ist es auch bei subversion nicht notwendig. Ich schaue es mir an…

comment:8 Geändert vor 9 Jahren durch er13

@HAL9000

Und den Teil

$(PKG)_BINARIES := $(strip $(foreach binary...

kannst Du mittlerweile durch

$(PKG)_BINARIES := $(call PKG_SELECTED_SUBOPTIONS,$($(PKG)_BINARIES_ALL))

ersetzen

comment:9 als Antwort auf: ↑ 6 Geändert vor 9 Jahren durch HAL 9000

Replying to er13:

Wenn das so ist, dann ist $(PKG)_BINARIES_BUILD_DIR falsch definiert und das ganze nur deswegen funktioniert, weil eins der Binaries in $(PKG)_DIR) liegt. Schaue Dir, wie es in den Makefiles von bluez-utils und quagga gelöst ist.

Stimmt, $(PKG)_BINARIES_BUILD_DIR ist falsch. Allerdings sind definitiv keine Binaries in $(PKG)_DIR), hab grad nochmal nachgesehen…

Geändert vor 9 Jahren durch HAL 9000

comment:10 Geändert vor 9 Jahren durch HAL 9000

Ich bin stecken geblieben :( Das, was ich jetzt habe, habe ich angehängt. Dabei habe ich an bluez-utils gehalten. Allerdings bekomme ich damit den Fehler:
make/reiserfsprogs/reiserfsprogs.mk:23: * Mehrfache Target-Muster. Schluss.
Leider verstehe ich nicht mal, was der Fehler genau bedeuten soll. Irgendwelche Tipps?

comment:11 als Antwort auf: ↑ description ; Antwort: Geändert vor 9 Jahren durch ralf

Mir ist folgende Konstruktion aufgefallen:

$(PKG)_BINARIES_ALL := reiserfsck mkreiserfs reiserfstune debugreiserfs resize_reiserfs 
$(PKG)_BINARIES := $(strip $(foreach binary,$($(PKG)_BINARIES_ALL),$(if $(FREETZ_PACKAGE_$(PKG)_$(shell echo $(binary) | tr [a-z] [A-Z])),$(binary))))

Hierbei wird für jedes der 5 Programme (foreach) eine Shell gestartet, die dann echo und tr aufruft. Je nachdem, wie die Shell das handhabt, sind das 2 oder 3 gestartete Prozesse, zusammen also 10 oder 15. Und das selbst dann, wenn das ganze Paket nicht ausgewählt ist. Die gleiche Problematik gibt es auch, wenn man statt dessen das vorgeschlagene Makro PKG_SELECTED_SUBOPTIONS verwendet. Da dies in immer mehr Paketen gemacht wird, ergibt sich eine deutliche Verzögerung beim Aufruf von make.

Dies läßt sich einfach vermeiden, wenn man den Namen des Programms in der Option gleich in Kleinbuchstaben schreibt, also FREETZ_PACKAGE_REISERFSPROGS_mkreiserfs statt FREETZ_PACKAGE_REISERFSPROGS_MKREISERFS.

comment:12 Geändert vor 9 Jahren durch er13

So, Makefile habe ich korrigiert. Testen konnte ich es allerdings nicht, denn es lässt sich bei mir nicht übersetzen. Ursache: fehlende printf.h bzw. die Struktur printf_info und die Funktion register_printf_function. Wenn sich das Ganze bei Dir übersetzen lässt, wo kommen diese bei Dir her? Hast Du selbst gebaute uClibc (um die oben genannten Header/Struktur/Funktion zu haben, müsstest Du UCLIBC_HAS_GLIBC_CUSTOM_PRINTF-Symbol aktiviert haben)? Oder hast Du reiserfsprogs irgendwie gepatched und vergessen die Patches anzuhängen? Hast Du die Binaries schon auf der Box laufen lassen?

comment:13 als Antwort auf: ↑ 11 ; Antwort: Geändert vor 9 Jahren durch er13

Replying to ralf:

Hierbei wird für jedes der 5 Programme (foreach) eine Shell gestartet, die dann echo und tr aufruft.

Ich habe es mal mit und ohne die shell-Aufrufe getestet. Der Unterschied liegt bei mir momentan bei etwa 0.4 Sec. Werden mehr Packages dieses Macro verwenden, so hast Du recht, kann es passieren, dass der Unterschied immer mehr spürbar wird. Daher der Vorschlag, wollen wir nicht die gmsl-Library einbinden. Diese stellt ein paar nützliche nur mit Hilfe der make-Funktionen umgesetzten Funktionen zur Verfügung, u.a. auch tr. Habe sie bei mir schon eingebunden, die 0.4 Sec. fallen wieder weg. Nachdem wir tr auch dafür verwenden, um PKG-Variable zu definieren, könnte theoretisch noch einiges an Zeit eingespart werden…

Edit: cool, die Library stellt sogar assert-Funktion zur Verfügung :)

comment:14 Geändert vor 9 Jahren durch HAL 9000

@er13: Erstmal danke fürs Makefile fixen :)
Zu dem Fehler: Den habe ich noch nie gesehen. Gepacht habe ich auch nichts weiter. Eben habe ich mal rumprobiert: Auf meiner Box (7140) lässt sich das ganze mit der download-toolchain (uclibc 0.9.28) bauen, mit der default-config (uclibc 0.9.29) dagegen nicht. Bei der ersteren existiert in toolchain/target/include auch eine printf.h, in der letzteren nich.

Geändert vor 9 Jahren durch er13

lässt sich nur mit selbstgebauter uClibc übersetzen

comment:15 als Antwort auf: ↑ 13 Geändert vor 9 Jahren durch ralf

Replying to er13:
Die gmsl-Library sieht interessant aus. Ich weiß, daß tr auch für jedes Package verwendet wird, aber dort ist mir keine so einfache Lösung dafür eingefallen wie beim Umbenennen der Config-Variablen. Bzw. da wäre die Umbenennung weitaus umfangreicher.

Kannst Du mal versuchen, auch da das tr-Makro einzusetzen und sehen, was es bringt?

Trotzdem bin ich dafür, bei den Config-Optionen die Programme in Kleinbuchstaben zu schreiben, bei den EXTERNAL-Optionen ist das auch der Fall. Man muß sich das Leben ja nicht unnötig schwer machen.

comment:16 Geändert vor 8 Jahren durch er13

(In [4900]) uClibc:

  • enable GLIBC_CUSTOM_PRINTF
  • refs #691

comment:17 Geändert vor 8 Jahren durch er13

(In [4967]) experimental toolchain:

  • enable GLIBC_CUSTOM_PRINTF
  • refs #691

comment:18 Geändert vor 8 Jahren durch cuma

  • Typ von enhancement nach addition geändert

comment:19 Geändert vor 6 Jahren durch cuma

  • Meilenstein von freetz-1.3 nach freetz-future geändert
Hinweis: Hilfe zur Verwendung von Tickets finden Sie in TracTickets.