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

molfi · 19 Jan 2012

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:

Code:

$(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

Code:

$(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:

Code:

$(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 · 19 Jan 2012

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

Code:

$(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

Code:

$(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:

Code:

$(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?

Code:

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.

molfi schrieb:
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:

Code:

[COLOR=red]select FREETZ_PACKAGE_CURL[/COLOR]

in deiner Config.in

er13 · 20 Jan 2012

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

Code:

select FREETZ_LIB_libcurl
select FREETZ_PACKAGE_CURL_WITH_SSL

ausreichen. Wegen falscher depends on musst Du momentan noch

Code:

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

Code:

$(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 · 20 Jan 2012

Ab r8485 sollte folgender Code in Config.in ausreichen:

Code:

select FREETZ_LIB_libcurl
select FREETZ_LIB_libcurl_WITH_SSL

oder

Code:

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.

Code:

$(PKG)_DEPENDS_ON := ....

in der .mk ist immer noch notwendig.

molfi · 21 Jan 2012

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 · 22 Jan 2012

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 · 23 Jan 2012

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 · 23 Jan 2012

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

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

Code:

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

aus deinem Build-System.

molfi · 24 Jan 2012

Hallo

Die Ausgabe lautet:

Code:

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 · 24 Jan 2012

molfi schrieb:
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 · 24 Jan 2012

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.

Code:

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?

Code:

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

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

Code:

$(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?

Code:

$(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.

Code:

$(SUBMAKE1) -C $(ESNIPER_DIR) \

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

Code:

$(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 · 24 Jan 2012

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

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

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

Ja.

molfi schrieb:
Code:

$(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.

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

Ja

molfi schrieb:
Code:

$(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".

molfi schrieb:
Code:

$(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 · 24 Jan 2012

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 · 24 Jan 2012

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

Code:

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

Code:

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 · 25 Jan 2012

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

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

Neuer User

IPPF-Promi

Aktives Mitglied

Aktives Mitglied

Neuer User

Anhänge

IPPF-Promi

Anhänge

Neuer User

Anhänge

IPPF-Promi

Neuer User

IPPF-Promi

Neuer User

IPPF-Promi

Neuer User

Aktives Mitglied

Neuer User

Statistik des Forums