[Gelöst] Wie configure Abhängigkeit zu Drittpaket Paket "coden"?

[molfi]

Hallo.

Ich versuche mich gerade an meinem ersten Freetz Package.
Wie das kompilieren durchläuft habe ich schon herausgefunden.

Das MYPACKAGE.mk enthält folgende Abhängigkeit:

$(PKG)_DEPENDS_ON := openssl curl

Curl muss allerdings wie folgt konfiguriert werden, sonst bricht configure meines MYPACKAGE ab mit dem Hinweis : no SSL support in curl

$(PKG)_CONFIGURE_OPTIONS += --with-ssl

Soweit ich die curl.mk verstehe geschieht dies nicht per default, sondern nur wenn curl explizit mit openssl support gewählt wird.


Nun könnte ich folgenden Code in the curl.mk patchen:

$(PKG)_CONFIGURE_OPTIONS += $(if $(FREETZ_PACKAGE_MYPACKAGE),--with-ssl)

Hier stellt sich mir folgende Frage:
Gibt es einen eleganteren Weg, mein Ziel zu erreichen, ohne die mk Datei eines anderen Pakets zu patchen?


Ich habe schon mal diverse mk Dateien anderer Packete durchgesehen, aber muss zugeben, einfach zu wenig Ahnung von der Materie zu haben.
... ich bin aber lernwillig und -fähig (hoffe ich zumindest)


Über einen Tip wäre ich sehr dankbar.

Und noch eine zweite Frage:
Gibt es auf freetz.org evtl irgendwo eine developer Übersicht über die ganzen Möglichkeiten in einer mk Datei? Sind das eine Art vordefinierte Makros?
zB
$(PKG)_CONFIGURE_OPTIONS
$(PKG)_REBUILD_SUBOPTS
$(PKG)_CONFIGURE_ENV
$(PKG)_AC_VARIABLES
$(PKG)_CONFIGURE_PRE_CMDS
etc
etc
etc


Gruß
molfi

 

[sf3978]

Das MYPACKAGE.mk enthält folgende Abhängigkeit:

$(PKG)_DEPENDS_ON := openssl curl

Curl muss allerdings wie folgt konfiguriert werden, sonst bricht configure meines MYPACKAGE ab mit dem Hinweis : no SSL support in curl

$(PKG)_CONFIGURE_OPTIONS += --with-ssl

Soweit ich die curl.mk verstehe geschieht dies nicht per default, sondern nur wenn curl explizit mit openssl support gewählt wird.


Nun könnte ich folgenden Code in the curl.mk patchen:

$(PKG)_CONFIGURE_OPTIONS += $(if $(FREETZ_PACKAGE_MYPACKAGE),--with-ssl)

Hier stellt sich mir folgende Frage:
Gibt es einen eleganteren Weg, mein Ziel zu erreichen, ohne die mk Datei eines anderen Pakets zu patchen?

ssl ist in CURL per default aktiviert. Oder hast Du was Anderes festgestellt?

config FREETZ_PACKAGE_[COLOR=red]CURL_WITH_SSL[/COLOR]
    bool "[COLOR=red]build with SSL support[/COLOR]"
    depends on FREETZ_PACKAGE_CURL
    [B]default[/B] [COLOR=red][B]y[/B][/COLOR]
    help
        This option enables SSL support in curl.

Und noch eine zweite Frage:
Gibt es auf freetz.org evtl irgendwo eine developer Übersicht über die ganzen Möglichkeiten in einer mk Datei? Sind das eine Art vordefinierte Makros?
zB
$(PKG)_CONFIGURE_OPTIONS
$(PKG)_REBUILD_SUBOPTS
$(PKG)_CONFIGURE_ENV
$(PKG)_AC_VARIABLES
$(PKG)_CONFIGURE_PRE_CMDS
etc
etc
etc

Schau dir in make die Makefile*-Dateien an.

EDIT:

Sollte es trotzdem nicht funktionieren, dann probier mal mit:

[COLOR=red]select FREETZ_PACKAGE_CURL[/COLOR]

in deiner Config.in

 

[er13]

Wenn alle freetz' depends on richtig wären, würde

select FREETZ_LIB_libcurl
select FREETZ_PACKAGE_CURL_WITH_SSL

ausreichen. Wegen falscher depends on musst Du momentan noch

select FREETZ_PACKAGE_CURL

dazu schreiben.

p.s. FREETZ_PACKAGE_CURL_WITH_SSL müsste eigentlich FREETZ_LIB_libcurl_WITH_SSL heißen.

Edit: ich korrigiere das mal bei Gelegenheit und gebe dann hier Bescheid.

Edit2: Und wenn Dein Paket nicht wirklich von openssl abhängt, sondern der einzige Grund, warum Du es in

$(PKG)_DEPENDS_ON := openssl curl

aufgenommen hast, der ist, damit curl mit openssl-Support übersetzt wird, dann reicht select FREETZ_PACKAGE_CURL_WITH_SSL in der Config.in aus, aus der .mk kannst und sollst Du die Dependency entfernen.

 

[er13]

Ab r8485 sollte folgender Code in Config.in ausreichen:

select FREETZ_LIB_libcurl
select FREETZ_LIB_libcurl_WITH_SSL

oder

select FREETZ_LIB_libcurl if !FREETZ_PACKAGE_YOURPACKAGE_STATIC
select FREETZ_LIB_libcurl_WITH_SSL

falls YOURPACKAGE eine Option zum statischen Linken anbietet.

Edit: "ausreichen" oben bezieht sich nur auf die Einträge in der Config.in.

$(PKG)_DEPENDS_ON := ....

in der .mk ist immer noch notwendig.

 

[molfi]

Vielen Dank.

Angehängtes Paket funktioniert nun mit r8485.
Ich musste dem make aber noch ein paar libs mit auf den Weg geben.


@sf3978: Richtig, SSL per default. Habe ich falsch interpretiert. Das curl Paket war nicht notwendig, die libs reichten. Auch Danke für den Tipp mit Makefile*

@er13: Anscheinend waren die depends in der mk Datei wirklich nicht von Nöten.
Worin besteht eigentlich der Unterschied, die curl und openssl dependencies in der mk Datei einzubetten oder sie über Freetz Pakete/Libs einzubinden?


Eine Bitte hätte ich noch an sf3978:
Ich habe Dein ursprüngliches Paket (klicke hier) soweit modifiziert, dass es sich wieder gegen den aktuelen Trunk kompilieren lässt.
Könntest Du nochmal über das angehängte Paket rüberschauen aus dem Blickwinkel eines Entwicklers im Hinblick darauf, ob es soweit ok ist oder gravierende Mängel bestehen?


Danke und Gruß
molfi

 

[sf3978]

Das statische linken der libraries funktioniert bei mir nicht. Im Anhang der angepasste Patch, u. a. auch ohne die Suboption für statisches Linken der libraries.

 

[molfi]

Ok, ich geh Deine Patch Datei die nächsten Tage durch, um die Unterschiede zu verstehen. Ich vermute es sind Freetz-spezifische Änderungen in Bezug auf die Struktur der mk Datei.

Anbei ein neuer Patch meinerseits, mit dem eigentlich nun das statische Linken funktionieren sollte. Wäre super, wenn Du den ausprobieren könntest.

Dank und Gruß
molfi

 

[sf3978]

Anbei ein neuer Patch meinerseits, mit dem eigentlich nun das statische Linken funktionieren sollte.

Poste mal nach dem "make <package>-precompiled", die Ausgabe von:

file packages/target-mipsel_uClibc-0.9.31.1/<package>-2-26-0/root/usr/bin/<package>

aus deinem Build-System.

 

[molfi]

Hallo

Die Ausgabe lautet:

freetz@freetz-linux:~$ cd trunk/
freetz@freetz-linux:~/trunk$ file packages/target-mipsel_uClibc-0.9.29/esniper-2-26-0/root/usr/bin/esniper
packages/target-mipsel_uClibc-0.9.29/esniper-2-26-0/root/usr/bin/esniper: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), statically linked, with unknown capability 0xf41 = 0x756e6700, stripped
freetz@freetz-linux:~/trunk$

Mir fällt allerdings die unterschiedliche uclibc auf.
Ich habe gestern ein frisches Freetz Linux samt frisch ausgechecktem trunk genutzt.

Gruß
molfi

 

[sf3978]

Mir fällt allerdings die unterschiedliche uclibc auf.
Ich habe gestern ein frisches Freetz Linux samt frisch ausgechecktem trunk genutzt.

Das ist von der Box abhängig. Bei dir 7170, bei mir 7240. Ist aber OK so.

 

[molfi]

Ok, dann habe ich mir Deinen Patch nochmal genauer angesehen und versuche ihn zu verstehen. Lasse mich bitte ein paar Fragen dazu stellen. ... in der Hoffnung, dass Du sie auch beantwortest.

make/esniper/Config.in
select FREETZ_LIB_libssl if !FREETZ_PACKAGE_ESNIPER_STATIC
select FREETZ_LIB_libcrypto if !FREETZ_PACKAGE_ESNIPER_STATIC
select FREETZ_LIB_libdl  if !FREETZ_PACKAGE_ESNIPER_STATIC
select FREETZ_LIB_libresolv if !FREETZ_PACKAGE_ESNIPER_STATIC
select FREETZ_LIB_libcurl if !FREETZ_PACKAGE_ESNIPER_STATIC
select FREETZ_LIB_libcurl_WITH_SSL

dies entscheidet doch, ob die libs mit ins Freetz Image eingebunden werden, oder?

make/esniper/esniper.mk
$(PKG)_SITE:=@SF/$(pkg)

verkürzte Schreibweise speziell für Sourceforge nehme ich an?

$(PKG)_DEPENDS_ON := curl openssl

warum eigentlich doch wieder die dependencies in der mk Datei?
er13 meinte, man sollte die dort leiber weglassen und in der Config.in pflegen.
funktionieren beide Wege, nur dieser hier bläht das Image nicht so doll auf?

$(PKG)_LIBS := -lresolv -lssl -lcrypto -lcurl -ldl

hier werden die libs dem linker übergeben während des make?
ldl muss irgendwie zwangsläufig ans Ende, sonst kompiliert er nicht richtig. Warum weiß ich nicht genau.

$(SUBMAKE1) -C $(ESNIPER_DIR) \

Ist das Freetz spezifisch und die neue Schreibweise für $(MAKE) -C $(ESNIPER_DIR) \ ?? Oder bewirkt SUBMAKE noch etwas anderes?

$(if $(FREETZ_PACKAGE_ESNIPER_STATIC),LDFLAGS=-static)

Hier könnte man doch sicher auch weiterhin mit der alten Schreibweise weitermachen, oder? LDFLAGS="$(TARGET_LDFLAGS) $(ESNIPER_LDFLAGS)" \


Gruß
molfi

 

[sf3978]

dies entscheidet doch, ob die libs mit ins Freetz Image eingebunden werden, oder?

Ja,damit diese auf der Box zur Verfügung stehen.

verkürzte Schreibweise speziell für Sourceforge nehme ich an?

Ja.

$(PKG)_DEPENDS_ON := curl openssl

warum eigentlich doch wieder die dependencies in der mk Datei?
er13 meinte, man sollte die dort leiber weglassen und in der Config.in pflegen.
funktionieren beide Wege, nur dieser hier bläht das Image nicht so doll auf?

Ich verstehe das so, dass es die Abhängigkeiten die im Build-System benötigt werden, sind.

hier werden die libs dem linker übergeben während des make?

Ja

$(SUBMAKE1) -C $(ESNIPER_DIR) \

Ist das Freetz spezifisch und die neue Schreibweise für $(MAKE) -C $(ESNIPER_DIR) \ ?? Oder bewirkt SUBMAKE noch etwas anderes?

Siehe in der "make/Makefile.in".

$(if $(FREETZ_PACKAGE_ESNIPER_STATIC),LDFLAGS=-static)

Hier könnte man doch sicher auch weiterhin mit der alten Schreibweise weitermachen, oder? LDFLAGS="$(TARGET_LDFLAGS) $(ESNIPER_LDFLAGS)" \

Ja.

 

[molfi]

ok, ich habe wieder ein wenig mehr verstanden.

Die make/Makefile.in gucke ich mir die nächsten Tage zu ende an.
.... auch wenn ich dort nicht so viel verstehe, so kann ich es als Nachschlagewerk für zukünftige "Projekte" nutzen.

Im Kopf habe ich
es-f.com
ca-certificates
python 2.6
heatpumpmonitor incl ein paar Modulen

Händisch habe ich mir das schon mal zusammengewürfelt und getestet.
Daraus ein lauffühiges Paket zu machen ist allerdings ne andere Nummer, ... auch wenn es sich nur um einen Patch handelt.


Wie auch immer, danke für Deine Hilfe und bereitwilliges Antwortgeben.

Gruß
molfi

 

[er13]

Mit Select-Einträgen in der Config.in werden in erster Linie die Runtime-Dependencies eines Pakets angegeben. D.h. damit wird angegeben, was alles zur Laufzeit gebraucht wird und daher mit ins Image aufgenommen werden soll.

Die DEPENDS_ON-Einträge in der .mk geben die Compile-Time-Dependencies eines Pakets an.

Wird Dein Paket statisch gelinkt, so ist zur Laufzeit keine libcurl notwendig, daher heißt es

select FREETZ_LIB_libcurl if !FREETZ_PACKAGE_YOURPACKAGE_STATIC

in der Config.in. Zur Compile-Zeit brauchst Du die Library jedoch immer, daher der entsprechende $(PKG)_DEPENDS_ON in .mk.

Ich habe meinen Beitrag oben editiert, da ich mich etwas missverständlich ausgedrückt habe. "ausreichen" bezog sich auf meinen Beitrag davor, in dem ich gesagt habe, dass man aufgrund eines Fehlers noch

select FREETZ_PACKAGE_CURL

benötigt. In r8485 habe ich den Fehler korrigiert und daher sollen die zwei (statt drei) Selects ausreichen.

p.s. Neben Runtime-Dependencies gibt es noch menuconfig-Optionen, mit denen gesteuert wird, mit welchen configure-Optionen ein Paket übersetzt werden soll. FREETZ_LIB_libcurl_WITH_SSL ist z.B. so eine Option.

 

[molfi]

super. Mit den Begriffen habe ich es nun auch zuordnen können und bin mir nun sicherer, was den Einsatz angeht.

Danke für Eure hilfe

molfi