freetz und interne libs

[The Hit-Man]

ich habe mir ein paar programme selbst erstellet, mit dem freetz toolchain. z.b. watch, abook, myman ( ncurses pacman ) und an mutt bin ich noch dran. nun möchte ich natürlich nicht alle programme statisch linken. bei manchen geht das ja auch nicht. um manche sachen dynamisch laufen zu lassen, brauche ich natürlich die libs als binary. die sind auch vorhanden und zwar unter /usr/lib/freetz. allerdings liegt da kein pfad drauf. so das ich beim starten meiner programme erst den library pfad erweitern muß damit diese auch gefunden werden per:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/freetz

dann läuft auch alles so weit ohne probleme.
meine frage ist jetzt, ist das normal, das man den pfad immer per hand erweitern muß oder gibts da irgendeine sache, die ich vielleicht übersehen habe. ich müßte ja mehr oder weniger immer ein shellscript vorschalten, der eben diesen pfad erweitert. das ist ein bischen unelegant.
ich habs auch schon in der rc.custom versucht den pfad zu erweitern aber da tut sich nichts.

weiß da jemand wie man das eleganter lösen könnte?

 

[PeterPawn]

RPATH in den fraglichen Binaries verwenden und dann NICHT von Freetz wieder rauspatchen lassen: http://tldp.org/HOWTO/Program-Library-HOWTO/index.html

 

[er13]

@The Hit-Man:
Beim Übersetzen der eigenen Programme mit der Freetz-Toolchain (genauer gesagt beim Linken) muss die Umgebungsvariable LD_RUN_PATH gesetzt sein oder der Linker mit dem Parameter rpath aufgerufen werden (s. z.B. diesen Thread). Dann wird RPATH in dem übersetzen Binary gesetzt und dann muss man zur Run-Time keinen Pfad zu LD_LIBRATY_PATH hinzufügen.

Alternativ müsste sich RPATH nachträglich mit patchelf setzen/ändern lassen. Dieses ist unter $(FREETZ_BUILD_ROOT)/tools/patchelf zu finden.

Edit1: mit patchelf lässt sich RPATH entweder komplett entfernen oder auf einen anderen nicht-längeren ändern. Wenn RPATH gar nicht gesetzt gewesen ist, so lässt sich damit nachträglich leider keins setzen.

Edit2: alternativ gibt es noch chrpath. Dieses hat aber dieselbe Einschränkung: "auf einen nicht-längeren". Dieses ist aber insofern besser, dass dieses die Prüfungen durchführt - sollte der neue Pfad zu lang sein, sagt chrpath es explizit und verweigert die Arbeit. patchelf kann dagegen das Binary kaputt patchen.

Welcher RPATH in dem Binary gesetzt ist, lässt sich wie folgt prüfen:

# readelf -d binary/library | grep RPATH
0x0000000f (RPATH)                      Library rpath: [/usr/lib/freetz]

---

und dann NICHT von Freetz wieder rauspatchen lassen

Was ist damit gemeint? An welcher Stelle patcht Freetz RPATH raus? Das einzige, was Freetz macht, ist, es sorgt dafür, dass LD_RUN_PATH Umgebungsvariable beim Übersetzen berücksichtigt wird, denn es gibt einige autoconf-basierte Pakete, bei denen der Compiler/Linker aktiv mit Parametern aufgerufen wird, die die Pfade aus LD_RUN_PATH übersteuern.

 

[PeterPawn]

Was ist damit gemeint?

Makefile.in:

227 # Fix configure and/or libtool scripts to prevent RPATH from being hardcoded.
228 # Based on ideas provided on http://wiki.debian.org/RpathIssue.

toolchain.in:

390 config FREETZ_RPATH
391         string "FREETZ_RPATH"
392         default "/usr/lib/freetz"
393         help
394                 A run-time search path (a colon-separated list of directories) to be hard-coded
395                 in all binaries/libraries compiled using Freetz toolchain.
396
397                 What is this needed for?
398                 Freetz provides some libraries (e.g. OpenSSL, Zlib, SQLite) which are also used
399                 by AVM in the original firmware. Freetz versions of these libraries are not (always)
400                 compatible with the AVM ones (Freetz might use a higher version number, a deviating
401                 configuration, different compiler settings, etc.). In order to avoid collisions
402                 with the AVM versions of the libraries Freetz libraries are put in a non-standard
403                 directory (non-standard from the dynamic loader point of view). This option allows
404                 the user to set this directory - it will be the 1st element of FREETZ_RPATH.
405
406                 Note: If you do NOT plan to flash the Freetz image and use the Freetz toolchain
407                       just for compiling the binaries/libraries then you can also set this option
408                       to one of the standard dynamic loader search paths (/usr or /usr/lib).
409                       In this case the resulting binaries/libraries won't contain an RPATH entry.

Line 409 "warnt" ja wohl ausdrücklich davor, daß bei Verwendung von "Standardpfaden" für FREETZ_RPATH gar kein RPATH-Entry im Binary landet, oder? Jedenfalls verstehe ich die Aussage so ...

Ich weiß zwar nicht (und will es auch gar nicht wissen, solange es für mich selbst keine wirkliche Bedeutung hat), was Freetz im Einzelnen mit RPATH macht. Ich weiß, daß es irgendwo im Makefile die Einträge in "FREETZ_RPATH" auseinanderpflückt und untersucht bzw. auch umbaut und ich kenne das Makro "PREVENT_RPATH_HARDCODING" - auch wenn letzteres wohl explizit aufgerufen werden muß und nicht in "PKG_INIT_{BIN|LIB}" implizit eingeschlossen wird? Wer sich ein Makefile mit einem solchen Aufruf als Template für ein eigenes Paket ausgesucht hat, der muß dann eben auch aufpassen, daß er - sofern vorhanden - einen solchen Aufruf ebenfalls entfernt - ansonsten patcht Freetz ihm die RPATH-Option direkt aus den "autoconf"-Files (primär wohl aus "configure") heraus, wenn ich das richtig lese.

Wenn ich ein eigenes Paket (das nicht zum Freetz-Portfolio gehört) für die Benutzung von RPATH konfiguriere (und das Paket unter der Freetz-Toolchain übersetzt werden soll, aber nichts mit "FREETZ_RPATH" am Hut hat und eine eigene Definition der Suchpfade verwendet), dann muß ich - sofern ich den "Hinweis" richtig interpretiere - unter der Freetz-Toolchain parallel noch dafür sorgen, daß FREETZ_RPATH auch auf irgendetwas "Unnormales" gesetzt ist ... ansonsten (bei /usr oder /usr/lib) entfernt der Konfigurationsprozess unter Freetz (ich würde mal annehmen, über die entsprechende Site-Konfiguration und offensichtlich "fummelt" das Makefile ja auch an "configure" bzw. "libtool" herum oder versucht es zumindest) die notwendigen Linker-Optionen wieder aus den Flags.

Wenn das nicht die Aussage des Hinweises (ab Zeile 406) sein soll, halte ich ihn für mißverständlich formuliert und das "prevent RPATH hardcoding" im Make-Kontext für eine merkwürdige und Mißverständnisse heraufbeschwörende Wortwahl ... mein "NICHT rauspatchen lassen" bezog sich jedenfalls auf die mit diesen Hinweisen und Fundstellen bei mir assoziierten Vorgänge, auch wenn ich da nicht weiter gesucht habe, wie die im Einzelnen realisiert sind oder was sie bewirken.

Da ich überwiegend statisch linke, damit die Programme (a) schnell zu installieren und (b) universeller auszuführen sind (die Größe interessiert mich erst dann, wenn die Images die 40 MB-Grenze reißen), juckt es mich bei meiner Verwendung (die Ergebnisse findet man ja in "yf_bin" als gesondertem Repo) auch nur in den allerseltensten Fällen, was Freetz da beim dynamischen Linken anstellt, denn das kommt fast nie zum Einsatz. Wenn ich dann wirklich mal etwas dynamisch linken lasse, steht bei mir "FREETZ_RPATH" auch auf "/var/custom/lib" ... was beim "Staging" zu sehr lustigen Ergebnissen im "packages"-Verzeichnis führt, weil der Inhalt dieser Variablen offenbar nicht nur für die Kodierung von RPATH-Entries in den Binaries verwendet wird (was man bei diesem Namen assoziieren würde), sondern "dual use" ist und irgendwo auch in die Bildung von Dateinamen für Ziele Einzug hält.

 

[The Hit-Man]

so, ich habe mich dem mal angenommen, 'myman', mit einem .mk file zu bauen. habe mir dann auch einige fertige .mk dateien angeschaut. so weit so gut, ein wenig steige ich da immer mehr durch. habe aber jetzt doch aber noch eine frage. da komme ich im moment nicht weiter ( wenn sie denn noch hier her gehört ).
habe alles im wiki befolgt um ein neues paker zu erstellen. und der befehl make myman-precompiled funtzt so weit auch, bis eben das configure aufgerufen wird.

meine myman.mk datei sieht bis jetzt so aus ( testweise ):

$(call PKG_INIT_BIN, wip-2009-10-30)
$(PKG)_SOURCE:=myman-$($(PKG)_VERSION).tar.gz
$(PKG)_SOURCE_MD5:=ffe2aeb4d41d12546e767f0aa4b0a213

$(PKG)_BINARY:=$($(PKG)_DIR)/src/myman
$(PKG)_TARGET_BINARY:=$($(PKG)_DEST_DIR)/usr/bin/myman

$(PKG_SOURCE_DOWNLOAD)
$(PKG_UNPACKED)
$(PKG_CONFIGURED_CONFIGURE)

$($(PKG)_BINARY): $($(PKG)_DIR)/.configured
    $(SUBMAKE) -C $(MYMAN_DIR)

$($(PKG)_TARGET_BINARY): $($(PKG)_BINARY)
    $(INSTALL_BINARY_STRIP)

$(pkg):

$(pkg)-precompiled: $($(PKG)_TARGET_BINARY)

$(pkg)-clean:
    -$(SUBMAKE) -C $(MYMAN_DIR) clean
    $(RM) $(MYMAN_DIR)/.configured

$(pkg)-uninstall:
    $(RM) $(MYMAN_TARGET_BINARY)

$(PKG_FINISH)

nun bekomme ich diese fehlermeldung vom Makefile:
configure: unrecognized option `--cache-file=/dev/null'

diese option, muß wohl aus freetz selber kommen wenn .configure aufgerufen wird. aber wie man sieht, gibt es diese option in dem ./configure nicht.
wie bekomme ich das weg? ich muß irgendwie freetz sagen, das er die option `--cache-file=/dev/null' nicht an das ./configure gibt.

 

[PeterPawn]

ich muß irgendwie freetz sagen, das er die option `--cache-file=/dev/null' nicht an das ./configure gibt.

Kleiner Tipp von mir für eine Alternative ... lasse lieber mit einem Patch-File in dem ur-ur-uralten "configure"-File die Behandlung unbekannter Optionen dahingehend ändern, daß die einfach ignoriert werden. Das dürfte die deutlich leichtere Änderung sein und schließt gleich alle weiteren, ggf. noch folgenden, unbekannten Optionen ebenfalls mit ein.

In Zeile 523 der Datei kannst Du ja sehen, daß bereits bei der ersten unbekannten Option mit "exit 2" die Verarbeitung beendet wird. Das wäre dann auch genau die Zeile, die man am besten durch ein "shift" ersetzt, damit wird nicht mehr abgebrochen, sondern die Option ignoriert.

Solange das die Langform einer Option ist und damit ein einzelner Parameter, reicht das einfache "shift" ... bei kurzer Option mit nachfolgendem Parameter wäre das dann nicht mehr so einfach (falls das noch ein Thema werden sollte bei diesem oder einem anderen Paket).

 

[The Hit-Man]

ich habe noch nie ein patch geschrieben ... habe mich immer davor gewehrt weil ich irgendwie dachte damit mache ich mir mehr kaputt als heile. ich habe das auch nie wirklich verstanden ich weiß zwar wasn patch ist aber ich weiß nicht wie man ihn einsetzt.

EDIT: hast du mal eben auf der schnelle das ./configure durch gesehen???

 

[The Hit-Man]

habe dann mal den shift gesetzt. nun aber:

creating directory obj/
/home/u0/freetz/7362SL/freetz-devel/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/bin/mips-linux-uclibc-gcc -march=24kc -mtune=24kc -msoft-float -Os -pipe -Wa,--trap -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_CONFIG_H=1 -Iinc -I. -Imygetopt -o obj/_sanity0.o -c obj/_sanity0.c
./_sanity0: ./_sanity0: Kann die Datei nicht ausführen.
make[1]: *** [makefile.cp:3253: obj/compiler.ok] Fehler 126

man man man, noch nie gelesen.

 

[er13]

Edit: das folgende ist die Antwort auf #5

Bei myman-wip-2009-10-30's configure script handelt es sich um ein handgeschriebenes configure und kein autoconf generiertes.

Du hast zwei 2 Alternativen:

• entweder wie von Peter vorgeschlagen das configure an der Stelle, an der die Fehlermeldung ausgegeben wird, so anpassen, dass die unbekannten Optionen einfach ignoriert werden
• Oder "$(PKG)_CONFIGURE_DEFOPTS := n" verwenden, s. die folgenden Pakete als Beispiel lsof.mk, ffmpeg.mk, openssl.mk