[Frage] "getdns"-Paket

zyrill

Neuer User
Mitglied seit
29 Jul 2009
Beiträge
89
Punkte für Reaktionen
0
Punkte
6
Hallo und danke erstmal für den Guide, der mir schon sehr weitergeholfen hat.


Vorstellung "demopackagea" und "demopackageb"

Ich würde gern getdns bzw. stubby (dns-over-tls) für die fritzbox kompilieren bin schon ein bisschen voran gekommen:
- Sourcen werden heruntergeladen
- TGZ wird entpackt
- Configure läuft (vermutlich) erfolgreich durch (libopenssl wird gefunden)

Dann habe ich allerdings ein Problem denn beim make findet er diverse Includes nicht, was dann so ausschaut:
Code:
make[2]: Entering directory '/home/pk/freetz/source/target-mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/getdns-1.2.0/src'
../libtool --quiet --tag=CC --mode=compile /home/pk/freetz/toolchain/build/mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/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 -Wpedantic -c ./const-info.c -o const-info.lo
In file included from ./const-info.c:6:0:
./getdns/getdns_extra.h:38:27: fatal error: getdns/getdns.h: No such file or directory
compilation terminated.
{standard input}: Assembler messages:
{standard input}: Warning: .gnu_attribute 4,3 requires `softfloat'
Makefile:119: recipe for target 'const-info.lo' failed
make[2]: *** [const-info.lo] Error 1
compilation terminated.
make[2]: Leaving directory '/home/pk/freetz/source/target-mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/getdns-1.2.0/src'
Makefile:53: recipe for target 'default' failed
make[1]: *** [default] Error 2
make[1]: Leaving directory '/home/pk/freetz/source/target-mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/getdns-1.2.0'

ERROR: Build failed.

Ich habe den Patch gegen master mit Config.in und getdns.mk angehängt. Wäre happy, wenn mir jemand kurz erklären könnte, was ich falsch mache - ich hab stundenlang gegoogelt und komme nicht weiter. Danke!

Zur Referenz hier die Homepage der Software: https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+Stubby
 

Anhänge

  • getdns.txt
    1.9 KB · Aufrufe: 11
Versuch's mal mit diesem Patch für Dein "mk"-File:
Code:
--- make/getdns/getdns.mk 
+++ make/getdns/getdns.mk 
@@ -9,7 +9,9 @@
 $(PKG)_CONFIGURE_OPTIONS += --without-libidn
 $(PKG)_CONFIGURE_OPTIONS += --enable-stub-only
 $(PKG)_CONFIGURE_OPTIONS += --with-stubby
-$(PKG)_CONFIGURE_OPTIONS += --with-ssl=$(TARGET_TOOLCHAIN_STAGING_DIR)/include
+
+$(PKG)_DEPENDS_ON += openssl
+$(PKG)_DEPENDS_ON += yaml

 $(PKG_SOURCE_DOWNLOAD)
 $(PKG_UNPACKED)
@@ -18,7 +20,7 @@
 $($(PKG)_BINARY): $($(PKG)_DIR)/.configured
   $(SUBMAKE) -C $(GETDNS_DIR) \
           CC="$(TARGET_CC)" \
-         CFLAGS="$(TARGET_CFLAGS)"
+         CFLAGS="$(TARGET_CFLAGS) -std=c99 -I$(FREETZ_BASE_DIR)/$(GETDNS_DIR)/src -I$(FREETZ_BASE_DIR)/$(GETDNS_DIR)/stubby/src"

 $($(PKG)_TARGET_BINARY): $($(PKG)_BINARY)
   $(INSTALL_BINARY_STRIP)
Kompiliert zwar auch noch nicht durch (scheitert irgendwo in "server.c" an einem "incomplete type"), aber kommt zumindest über die Hürden mit den fehlenden Include-Files hinweg (das Verzeichnis mit den Quellen ist halt nicht im "Include-Path") und kompiliert die ersten Dateien aus dem Projekt. Welche Patches da ggf. noch notwendig sind, damit das mit der uClibc auch zurechtkommt, mußt Du selbst sehen.

Ist auch nur eine erste Änderung für die Datei ... alternativ wäre die Änderung von $(TARGET_CFLAGS) auf einer gesonderten Zeile denkbar. Da gibt es aber im "Freetz" bisher keine belastbaren "Regeln" ... die sollen aber "in Arbeit" sein.
 
  • Like
Reaktionen: tuxedonet
Danke vielmals für Deine Hilfe, PeterPawn.

Ohne
$(PKG)_CONFIGURE_OPTIONS += --with-ssl=$(TARGET_TOOLCHAIN_STAGING_DIR)/include
bekomme ich wieder die Fehlermeldung, die ssl libs würden nicht gefunden:
Code:
checking for SSL... configure: error: Cannot find the SSL libraries in /usr/local/ssl /usr/lib/ssl /usr/ssl /usr/pkg /usr/local /opt/local /usr/sfw /usr

ERROR: Build failed.
make/getdns/getdns.mk:18: recipe for target 'source/target-mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/getdns-1.2.0/.configured' failed
make: *** [source/target-mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/getdns-1.2.0/.configured] Error 1

Also habe ich die with-ssl Zeile belassen und Deine anderen Änderungen übernommen; jetzt bekomme ich auch die von Dir beschriebene server.c Fehlermeldung.

Ich arbeite mit diesem Stand einfach mal weiter und robbe mich Richtung Build. Mühsam ernährt sich das (ignorante) Eichhörnchen - aber ich machs ja auch zum Lernen. :)

Danke jedenfalls nochmal herzlichst für die Hilfe!
 
Interessant ... bei mir werden die entsprechenden Dateien vom "configure" gefunden, sofern die Pakete vor "getdns" gebaut wurden - daher die zusätzlichen "DEPENDS_ON" in der Datei, damit diese zuerst erzeugt werden (das "SELECT" in der "Config.in" reicht für die richtige Reihenfolge nicht aus).

Welche Version von OpenSSL wird bei Dir denn verwendet? Es gab ja auch in jüngerer Vergangenheit noch genug Freetz-Benutzer, die schon über Jahre die alte Version 0.9.8 in ihrer immer wieder neu verwendeten Freetz-Konfiguration einfach mitgeschleppt haben.

Angesichts des "Alters" von "getdns" (auch das DNS over TLS ist ja noch nicht so lange festgeklopft) würde ich mal darauf tippen (ohne jetzt nachzuschauen), daß "getdns" mind. OpenSSL 1.0.1 erwartet. Vielleicht schaust Du ja dort noch einmal nach - eine Überprüfung kann eigentlich nie schaden, besonders dann, wenn Du schon sehr lange mit derselben Freetz-Konfiguration arbeitest. Es gab zwar letztens auch ein paar Änderungen in den Kconfig-Dateien bzgl. der OpenSSL-Versionen ... aber ich weiß nicht, ob nicht weiterhin die Auswahl von 0.9.8 auch für neuere Firmware möglich ist und nur strikter davor gewarnt wird (und auch da schaue ich jetzt nicht extra nach).

EDIT: Vielleicht machst Du ja auch besser einen neuen Thread auf und läßt von einem Moderator die Beiträge ab #53 dorthin verschieben ... ein funktionierendes "getdns"-Paket wäre ja eine schöne Alternative zum "dnsmasq"-Paket mit weitaus weniger Konfigurationsaufwand (und damit auch mit weniger potentiellen Fehlerquellen, ergo auch "für Laien" einfacher zu benutzen) und das sollte schon ein eigenes Thema wert sein, wenn Du das soweit betreiben willst, daß auch eine Konfigurationsmöglichkeit dafür in den Freetz.-Mod integriert wird.

EDIT2: Da lag ich (zumindest was die Voraussetzungen für DNS over TLS angeht, ob ich bei Deiner Konfiguration richtig getippt habe, weiß ich natürlich nicht) dann doch nicht so ganz falsch:

https://getdnsapi.net/documentation/readme/
 
Zuletzt bearbeitet:
Super, danke, stoney!

Habe mir die Compilerfehler näher angesehen und ein hoher Anteil (die u_int, u_char und netdns Fehler) scheint von dem Flag "-std=c99" zu kommen - brauchen wir jenes Flag zwangsläufig?
 
Irgendwo gab es gleich am Beginn (späte) Initialisierungen von Variablen auf Block-Ebene ... laß die Option für den C-Dialekt doch einfach mal weg und schau Dir an, was dann passiert.

Anschließend kannst Du Dir anhand der dann auftretenden Fehler einen "Dialekt" aussuchen: https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#C-Dialect-Options

Abgesehen davon kann niemand hier wissen, was mit den "u_int, u_char und netdns Fehlern" wohl gemeint sein könnte ... ich hatte davon keine, lediglich den "incomplete type", der bei der Anwendung von "sizeof()" halt zum Fehler führt - ist ja logisch, daß die Speicher-Größe einer nicht vollständigen Definition nicht ermittelt werden kann. Warum die Struktur (war glaube ich eine "addrinfo") nun unvollständig ist, habe ich nicht nachgesehen ... aber an "u_int" lag es eher nicht, iirc.

Abgesehen davon sollte bei einem halbwegs modernen C-Quelltext (und die libgetdns sollte dazugehören) auch die Verwendung von C99 kein Problem sein ... ich bin mir nicht so ganz sicher, ob Du da auf der "richtigen Spur" bist - ich würde es eher bezweifeln (was Dich nicht davon abhalten sollte, das selbst gründlich zu recherchieren).
 
Ich habe mal eine saubere Baseline gezogen, das freetz Verzeichnis komplett gelöscht und neu geclont, weil ich so viel rumgefrickelt habe. Also neu aufgesetzt, getdns Verzeichnis hinzugefügt, getdns ausgewählt und mal versucht, zu bauen. Ich komme allerdings jetzt nicht mal mehr bis zum getdns Build, weil irgendwas beim Build von der lib openssl klemmt:
Code:
chmod 755 /home/pk/freetz/toolchain/build/mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/mips-linux-uclibc/usr/lib/libssl.so.; mkdir -p packages/target-mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/root/usr/lib/freetz/; rm -f ; cp -a  packages/target-mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/root/usr/lib/freetz/; /home/pk/freetz/toolchain/build/mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/mips-linux-uclibc/bin/mips-linux-uclibc-strip --remove-section={.comment,.note,.pdr} packages/target-mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/root/usr/lib/freetz/libssl.so.;
chmod: cannot access '/home/pk/freetz/toolchain/build/mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/mips-linux-uclibc/usr/lib/libssl.so.': No such file or directory
cp: missing destination file operand after 'packages/target-mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/root/usr/lib/freetz/'
Try 'cp --help' for more information.
/home/pk/freetz/toolchain/build/mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/mips-linux-uclibc/bin/mips-linux-uclibc-strip: 'packages/target-mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/root/usr/lib/freetz/libssl.so.': No such file
make/openssl/openssl.mk:89: recipe for target 'packages/target-mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/root/usr/lib/freetz/libssl.so.' failed
make: *** [packages/target-mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/root/usr/lib/freetz/libssl.so.] Error 1
Genug für dieses Wochenende. Gute Nacht und nochmal danke für die anhaltende Hilfe!
 

Anhänge

  • Config.in.txt
    426 Bytes · Aufrufe: 3
  • getdns.mk.txt
    1.1 KB · Aufrufe: 5
ich kenne keine Freetz-Variable "FREETZ_LIB_libopenssl" in der Datei "make/getdns/Config.in"
IMHO, da sollte doch "select FREETZ_LIB_libssl" drinn stehen.

ansonsten schadet es nicht, wenn man bei Freetz-Problemen immer die ".Config" Datei sowie das Logfile "fmake.log" (erhält man nach absetzen des Befehls "./fmake -c") dem Thread beifügt.
Dann hat man die Chance es nachzuvollziehen und kann ggf. effizienter helfen.

EDIT1:
die Suche liefert folgenden Thread mit gleicher Fehlermeldung:
https://www.ip-phone-forum.de/threads/curl-7-55-1-als-statically-linked-binary.296738/#post-2240713

hier hat das Hinzufügen von "select FREETZ_OPENSSL_VERSION_PROMPT" das Problem gefixt;
entsprechender Patch für getdns:
Code:
--- make/getdns/Config.in     2017-10-30 13:20:11.469618213 +0100
+++ make/getdns/Config.in     2017-10-30 13:20:29.979020893 +0100
@@ -1,5 +1,7 @@
 config FREETZ_PACKAGE_GETDNS
        bool "getdns 1.2.0"
        select FREETZ_LIB_libyaml
+        select FREETZ_OPENSSL_VERSION_PROMPT
+        select FREETZ_LIB_libcrypto
         select FREETZ_LIB_libopenssl
        default n

weitere hilfreiche Befehle
Befehle:
Code:
make openssl-distclean
make openssl-precompiled 2>&1 | tee openssl-precompiled.log
d.h. Bitte Datei openssl-precompiled.log als Attachement dem Thread beifügen.
 
Zuletzt bearbeitet:
Sorry für die dünne Infolage, tuxedonet. Und danke für die Hinweise, werde ich in Zukunft berücksichtigen. Habe das select statement gefixt, Problem bleibt allerdings bestehen: selber Fehler.
 

Anhänge

  • .config.txt
    18.3 KB · Aufrufe: 1
  • fmake.log.txt
    253.6 KB · Aufrufe: 3
Wenn man das Paket in einer Freetz-Installation "from scratch" bauen will, müssten (als Beispiel) folgende Einstellungen in der "Config.in" vorhanden sein:
Code:
config FREETZ_PACKAGE_GETDNS
        bool "getdns 1.2.0"
        select FREETZ_LIB_libyaml
        select FREETZ_OPENSSL_VERSION_PROMPT
        select FREETZ_OPENSSL_VERSION_1_REQUIRED
        select FREETZ_LIB_libssl
        select FREETZ_LIB_libcrypto
        default n
Mit "libssl" vs. "libopenssl" hat @tuxedonet recht und ohne die Auswahl der OpenSSL-Version über "FREETZ_OPENSSL_VERSION_PROMPT" wird der Suffix für die DSO-Version der Lib nicht richtig gesetzt, was dann bei der Installation zum o.a. Fehler führt. Da "getdns" für DNS over TLS ja die Version 1.0.1 braucht und das offenbar der "angedachte" Verwendungszweck wäre (die "libgetdns" hat ja noch andere Funktionen), ist die Auswahl von FREETZ_OPENSSL_VERSION_1_REQUIRED auch nur logisch.

Da ein "SELECT FREETZ_LIB_libssl" auch nicht automatisch alle Abhängigkeiten auflöst (siehe https://www.kernel.org/doc/Documentation/kbuild/kconfig-language.txt), braucht es i.d.R. auch noch die "manuelle automatische Auswahl" ( :D ) von "libcrypto" als Voraussetzung für das Funktionieren der "libssl".

Mit diesen Änderungen funktioniert dann auch die Konfiguration von OpenSSL für "getdns" auf der Basis der "site configuration" und ohne die Angabe irgendwelcher Verzeichnisse für OpenSSL:
Code:
checking for SSL... found in /usr
checking for HMAC_Update in -lcrypto... yes
checking for openssl/ssl.h... (cached) yes
checking for openssl/err.h... (cached) yes
checking for openssl/rand.h... (cached) yes
checking for TLSv1_2_client_method... (cached) yes
checking for SSL_CTX_get0_param... (cached) yes
checking if libssl needs libdl... no
checking for LibreSSL... no
checking for openssl/conf.h... (cached) yes
checking for openssl/engine.h... (cached) yes
checking for openssl/bn.h... (cached) yes
checking for openssl/rsa.h... (cached) yes
checking for openssl/dsa.h... (cached) yes
checking for OPENSSL_config... (cached) yes
checking for EVP_md5... (cached) yes
checking for EVP_sha1... (cached) yes
checking for EVP_sha224... (cached) yes
checking for EVP_sha256... (cached) yes
checking for EVP_sha384... (cached) yes
checking for EVP_sha512... (cached) yes
checking for FIPS_mode... (cached) yes
checking for ENGINE_load_cryptodev... (cached) yes
checking for EVP_PKEY_keygen... (cached) yes
checking for ECDSA_SIG_get0... (cached) no
checking for EVP_MD_CTX_new... (cached) no
checking for EVP_PKEY_base_id... (cached) yes
checking for HMAC_CTX_new... (cached) no
checking for HMAC_CTX_free... (cached) no
checking for TLS_client_method... (cached) no
checking for DSA_SIG_set0... (cached) no
checking for EVP_dss1... (cached) yes
checking for EVP_DigestVerify... (cached) no
checking for SSL_CTX_set_min_proto_version... (cached) no
checking whether SSL_COMP_get_compression_methods is declared... (cached) yes
checking whether sk_SSL_COMP_pop_free is declared... (cached) yes
checking whether SSL_CTX_set_ecdh_auto is declared... (cached) yes
checking for EVP_PKEY_set_type_str... (cached) yes
checking for EC_KEY_new... (cached) yes
checking if GOST works... maybe
checking for ECDSA_sign... (cached) yes
checking for SHA384_Init... (cached) yes
checking whether NID_X9_62_prime256v1 is declared... (cached) yes
checking whether NID_secp384r1 is declared... (cached) yes
checking if openssl supports SHA2 and ECDSA with EVP... yes
checking for DSA_SIG_new... (cached) yes
Bei der Übersetzung trifft man dann (sofern man den C-Dialekt nicht festlegt) dank des "-Wpedantic" auf jede Menge Warnungen, weil viele Elemente genutzt werden, die im C90-Standard nicht vorhanden sind, z.B. Makros mit variabler Parameterliste (also "(...)" in der Definition und "__VA_ARGS__" in der Auflösung). Schaut man in die "configure.ac" für das Paket hinein, findet man dort die automatische Konfiguration des richtigen Dialekts:
Code:
AC_PROG_CC_C99
Das "configure" erledigt das in der Freetz-Toolchain dann dahingehend, daß "-std=gnu99" verwendet wird - sieht man im erzeugten "Makefile" für die Übersetzungen in "src".

Die notwendigen Verzeichnisse für zusätzliche Include-Files findet man dann in der jeweiligen "Makefile.in" und das sieht für "src" z.B. dann so aus:
Code:
[...]
srcdir = @srcdir@
stubbysrcdir = $(srcdir)/../stubby
LIBTOOL = ../libtool

CC=@CC@
CFLAGS=-I$(srcdir) -I. -I$(srcdir)/util/auxiliary -I$(stubbysrcdir)/src @CFLAGS@ @CPPFLAGS@ $(XTRA_CFLAGS)
[...]
Gesetzt den Fall, man kriegt die Variable "srcdir" auf den richtigen Wert mit der (absoluten) Verzeichnisangabe für das Source-Verzeichnis in der Toolchain, braucht man die also auch nicht von Hand festlegen. Also geht es darum, wie man "srcdir" (als Variable beim "autoconf") nun auf den richtigen Wert bringt.

Die naheliegendste Variante wäre die Angabe beim Aufruf von "configure", was in "getdns.mk" dann in etwa so aussehen würde:
Code:
$(PKG)_CONFIGURE_OPTIONS += --srcdir=$(FREETZ_BASE_DIR)/$($(PKG)_DIR)
Leider enthält aber die (aktuell mit autoconf 2.69 erstellte) "configure"-Datei auch die folgende Passage:
Code:
# When building in place, set srcdir=.
if test "$ac_abs_confdir" = "$ac_pwd"; then
  srcdir=.
fi
Wenn man die jetzt aber einfach herauspatcht, dann kann man sich vom "configure" brauchbare "Makefile"-Ausgaben erzeugen lassen.

Dann muß man nur noch auf die explizite Angabe von "CC" und "CFLAGS" beim Aufruf von "make" für das Source-Paket verzichten (weil die ohne "override" o.ä. im erzeugten "Makefile" festgelegt werden und daher die Angabe beim Aufruf den Wert aus dem "configure"-Lauf überlagert) und es klappt schon mal beim "make" bis zu der Stelle, wo irgendetwas im Staging-Directory installiert werden soll.

Das "Gehuddel" mit den Verzeichnissen (und der Patch) ist notwendig, weil in der Freetz-Toolchain beim Aufruf von "configure" tatsächlich das Verzeichnis mit den Quellen des Paketes (in source/target.../<package>) das aktuelle ist, was aber beim Aufruf von irgendwelchen Makefiles dann nicht mehr der Fall ist (hier ist es "FREETZ_BASE_DIR").

Nun könnte man zwar vor dem Aufruf von "make" in Unterverzeichnissen erst mal noch ein "cd" einbauen, aber das bringt dann u.U. andere unerwünschte Wirkungen, wenn irgendwelche Tools nicht mehr gefunden werden, weil die nur mit relativen Pfaden arbeiten/adressiert werden und dabei von FREETZ_BASE_DIR ausgegangen wird. Da ist es dann günstiger, die Angaben für das neue Paket jeweils "komplett" zu machen, daher auch das Festlegen eines "absoluten" Pfades für "srcdir" weiter oben.

Beim Linken muß man sich dann halt entscheiden, ob man wirklich mit DSO arbeiten will für die "libgetdns" oder nicht. Entweder man muß die dann auch noch mit installieren im Staging-Directory (und dann ist das am Ende eher ein "Library-Paket" als eines für "Binaries" bzw. ein "gemischtes") oder man linkt sich "stubby" statisch mit der "libgetdns" (und vielleicht auch gleich noch mit der "libyaml", falls man nicht gerade zwei Pakete hat, welche die verwenden wollen - wobei man dann auch auf das "SELECT FREETZ_LIB_libyaml" verzichten kann, wenn man die nicht installieren will; das "DEPENDS_ON" gehört aber weiterhin in die "Config.in" die "getdns.mk", damit die Lib vor "getdns" gebaut wird) und benutzt nur die OpenSSL-Bibliotheken (nur die werden halt auch von anderen Paketen gebraucht) gemeinsam.

Dazu muß man aber das Linker-Kommando für "stubby" dann entsprechend anpassen - wobei es ohnehin kein "getdns"-Binary gibt, wie es das "getdns.mk" aus Deiner Version nahelegen würde.

Bis zum Linken/Installieren klappt das schon mal mit den Dateien im Anhang ... aber vielleicht versuchst Du Dich ja doch erst noch einmal selbst am Thema, denn wenn ich das richtig verstanden habe, stand ja auch der gewünschte Lernerfolg im Fokus und das Programm war nur Mittel zum Zweck.

PS: Das "enable-shared" beim "configure" habe ich schon rausgenommen, weil ich selbst das eher statisch linken würde ... ohne diese Entscheidung müßte es wieder rein in die "getdns.mk".
 

Anhänge

  • getdns.zip
    1.9 KB · Aufrufe: 12
Zuletzt bearbeitet:
Habe das select statement gefixt, Problem bleibt allerdings bestehen: selber Fehler.

da fehlt doch der "make menuconfig" bzw. "make oldconfig" Befehl nach Einrichten des Packages "getdns", d.h. Implementierung der Dateien "make/getdns/Config.in" sowie "make/getdns/getdns.mk";
siehe
Code:
freetz@raspi:~/freetz-trunk$ grep -i getdns .config
freetz@raspi:~/freetz-trunk$

freetz@raspi:~/freetz-trunk$ grep -i openssl .config
FREETZ_OPENSSL_LIBCRYPTO_EXTRA_LIBS="-ldl"
FREETZ_AVM_HAS_OPENSSL=y
FREETZ_AVM_HAS_OPENSSL_VERSION_1=y
freetz@raspi:~/freetz-trunk$

freetz@raspi:~/freetz-trunk$ make oldconfig
SNIP
getdns 1.2.0 (FREETZ_PACKAGE_GETDNS) [N/y/?] (NEW) y
SNIP
* OpenSSL --------------------------------
*
OpenSSL cryptographic library (libcrypto.so) (FREETZ_LIB_libcrypto) [Y/?] y
  OpenSSL SSL/TLS library (libssl.so) (FREETZ_LIB_libssl) [Y/?] (NEW) y
OpenSSL version
> 1. 1.0.2 (FREETZ_OPENSSL_VERSION_1) (NEW)
choice[1]: 1
*
* OpenSSL configuration
*
Support elliptic curve cryptography (FREETZ_LIB_libcrypto_WITH_EC) [N/y/?] (NEW)
Support RC4 cipher (NOT RECOMMENDED) (FREETZ_LIB_libcrypto_WITH_RC4) [N/y/?] (NEW)
Build with zlib support (FREETZ_LIB_libcrypto_WITH_ZLIB) [N/y] (NEW)
Reduce the footprint of OpenSSL libraries (FREETZ_OPENSSL_SMALL_FOOTPRINT) [Y/n/?] (NEW)
OpenSSL configuration directory (FREETZ_OPENSSL_CONFIG_DIR) [/mod/etc/ssl] (NEW)
*
* PolarSSL -------------------------------
*
PolarSSL-1.2.x (libpolarssl12.so) (FREETZ_LIB_libpolarssl12) [N/y/?] n
PolarSSL-1.3.x (libpolarssl13.so) (FREETZ_LIB_libpolarssl13) [N/y/?] n
#
# configuration written to .config
#
freetz@raspi:~/freetz-trunk$

freetz@raspi:~/freetz-trunk$ grep -i getdns .config
FREETZ_PACKAGE_GETDNS=y
freetz@raspi:~/freetz-trunk$

freetz@raspi:~/freetz-trunk$ grep -i openssl .config
# FREETZ_PACKAGE_OPENSSL is not set
# FREETZ_PACKAGE_TRANSMISSION_WITH_OPENSSL is not set
# OpenSSL --------------------------------
FREETZ_OPENSSL_VERSION_PROMPT=y
FREETZ_OPENSSL_VERSION_1_REQUIRED=y
FREETZ_OPENSSL_VERSION_1=y
FREETZ_OPENSSL_SHLIB_VERSION="1.0.0"
FREETZ_OPENSSL_LIBCRYPTO_EXTRA_LIBS="-ldl"
# OpenSSL configuration
FREETZ_OPENSSL_SMALL_FOOTPRINT=y
FREETZ_OPENSSL_CONFIG_DIR="/mod/etc/ssl"
## FREETZ_BUSYBOX_FEATURE_WGET_OPENSSL is not set
FREETZ_AVM_HAS_OPENSSL=y
# FREETZ_AVM_HAS_OPENSSL_VERSION_0 is not set
FREETZ_AVM_HAS_OPENSSL_VERSION_1=y
freetz@raspi:~/freetz-trunk$ #
 
Nochmals: vielen Dank für die Hilfe - die Lernkurve ist ziemlich steil. Ich habe allerdings make menuconfig ausgeführt.
Code:
 grep -i getdns .config
FREETZ_PACKAGE_GETDNS=y
pk@kali:~/freetz$ grep -i openssl .config
# FREETZ_PACKAGE_OPENSSL is not set
# FREETZ_PACKAGE_TRANSMISSION_WITH_OPENSSL is not set
# OpenSSL --------------------------------
FREETZ_OPENSSL_VERSION_PROMPT=y
FREETZ_OPENSSL_VERSION_1_REQUIRED=y
FREETZ_OPENSSL_VERSION_1=y
FREETZ_OPENSSL_SHLIB_VERSION="1.0.0"
FREETZ_OPENSSL_LIBCRYPTO_EXTRA_LIBS="-ldl"
# OpenSSL configuration
FREETZ_OPENSSL_SMALL_FOOTPRINT=y
FREETZ_OPENSSL_CONFIG_DIR="/mod/etc/ssl"
# FREETZ_BUSYBOX_FEATURE_WGET_OPENSSL is not set
FREETZ_AVM_HAS_OPENSSL=y
# FREETZ_AVM_HAS_OPENSSL_VERSION_0 is not set
FREETZ_AVM_HAS_OPENSSL_VERSION_1=y

Und dennoch:
Code:
checking for SSL... configure: error: Cannot find the SSL libraries in /usr/local/ssl /usr/lib/ssl /usr/ssl /usr/pkg /usr/local /opt/local /usr/sfw /usr

ERROR: Build failed.
make/getdns/getdns.mk:20: recipe for target 'source/target-mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/getdns-1.2.0/.configured' failed
make: *** [source/target-mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/getdns-1.2.0/.configured] Error 1

Ist ja auch klar, hier liegt nix: " /usr/local/ssl /usr/lib/ssl /usr/ssl /usr/pkg /usr/local /opt/local /usr/sfw /usr". Gesucht werden soll in "/home/pk/freetz/toolchain/build/mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/mips-linux-uclibc/lib" oder?

Sollte der Pfad, wo er die libopenssl sucht nicht sein: "/home/pk/freetz/toolchain/build/mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/mips-linux-uclibc/lib"?

Also habe ich spaßeshalber in der getdns.mk nochmal eingefügt:
Code:
$(PKG)_CONFIGURE_OPTIONS += --with-ssl=$(TARGET_TOOLCHAIN_STAGING_DIR)/lib
denn in dem Verzeichnis liegen sämtliche libs:
Code:
ll toolchain/build/mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/mips-linux-uclibc/mips-linux-uclibc/lib/
total 20004
-rw-r--r-- 1 pk pk    1364 Oct 29 22:36 Scrt1.o
-rw-r--r-- 1 pk pk    1364 Oct 29 22:36 crt1.o
-rw-r--r-- 1 pk pk    1536 Oct 29 22:36 crti.o
-rw-r--r-- 1 pk pk    1232 Oct 29 22:36 crtn.o
drwxr-xr-x 1 pk pk       0 Oct 29 22:54 engines
drwxr-xr-x 1 pk pk      34 Oct 29 22:35 gcc
-rwxr-xr-x 1 pk pk   34988 Oct 29 22:36 ld-uClibc-0.9.33.2.so
lrwxrwxrwx 1 pk pk      21 Oct 29 22:36 ld-uClibc.so.0 -> ld-uClibc-0.9.33.2.so
drwxr-xr-x 1 pk pk    2388 Oct 29 22:29 ldscripts
-rw-r--r-- 1 pk pk   80406 Oct 29 22:44 libatomic.a
-rwxr-xr-x 1 pk pk    1064 Oct 29 22:44 libatomic.la
lrwxrwxrwx 1 pk pk      18 Oct 29 22:44 libatomic.so -> libatomic.so.1.1.0
lrwxrwxrwx 1 pk pk      18 Oct 29 22:44 libatomic.so.1 -> libatomic.so.1.1.0
-rwxr-xr-x 1 pk pk   27624 Oct 29 22:44 libatomic.so.1.1.0
-rw-r--r-- 1 pk pk 2149008 Oct 29 22:36 libc.a
-rwxr-xr-x 1 pk pk     324 Oct 29 22:36 libc.so
lrwxrwxrwx 1 pk pk      21 Oct 29 22:36 libc.so.0 -> libuClibc-0.9.33.2.so
-rw-r--r-- 1 pk pk 2142870 Oct 29 22:36 libc_pic.a
-rwxr-xr-x 1 pk pk    1016 Oct 29 22:44 libcc1.la
lrwxrwxrwx 1 pk pk      15 Oct 29 22:44 libcc1.so -> libcc1.so.0.0.0
lrwxrwxrwx 1 pk pk      15 Oct 29 22:44 libcc1.so.0 -> libcc1.so.0.0.0
-rwxr-xr-x 1 pk pk  119208 Oct 29 22:44 libcc1.so.0.0.0
-rwxr-xr-x 1 pk pk   16240 Oct 29 22:36 libcrypt-0.9.33.2.so
-rw-r--r-- 1 pk pk   17390 Oct 29 22:36 libcrypt.a
lrwxrwxrwx 1 pk pk      13 Oct 29 22:36 libcrypt.so -> libcrypt.so.0
lrwxrwxrwx 1 pk pk      20 Oct 29 22:36 libcrypt.so.0 -> libcrypt-0.9.33.2.so
lrwxrwxrwx 1 pk pk      10 Oct 29 22:36 libcrypt_pic.a -> libcrypt.a
-rw-r--r-- 1 pk pk 3583610 Oct 30 20:49 libcrypto.a
lrwxrwxrwx 1 pk pk      18 Oct 30 20:49 libcrypto.so -> libcrypto.so.1.0.0
-rwxr-xr-x 1 pk pk 1746708 Oct 30 20:49 libcrypto.so.1.0.0
-rwxr-xr-x 1 pk pk   16496 Oct 29 22:36 libdl-0.9.33.2.so
-rw-r--r-- 1 pk pk   29836 Oct 29 22:36 libdl.a
lrwxrwxrwx 1 pk pk      10 Oct 29 22:36 libdl.so -> libdl.so.0
lrwxrwxrwx 1 pk pk      17 Oct 29 22:36 libdl.so.0 -> libdl-0.9.33.2.so
-rw-r--r-- 1 pk pk   13002 Oct 29 22:36 libdl_pic.a
lrwxrwxrwx 1 pk pk      49 Oct 29 22:44 libgcc.map -> ../usr/lib/gcc/mips-linux-uclibc/5.4.0/libgcc.map
lrwxrwxrwx 1 pk pk      51 Oct 29 22:44 libgcc_pic.a -> ../usr/lib/gcc/mips-linux-uclibc/5.4.0/libgcc_pic.a
-rw-r--r-- 1 pk pk     132 Oct 29 22:44 libgcc_s.so
-rwxr-xr-x 1 pk pk   61724 Oct 29 22:44 libgcc_s.so.1
-rwxr-xr-x 1 pk pk  172556 Oct 29 22:36 libm-0.9.33.2.so
-rw-r--r-- 1 pk pk  327546 Oct 29 22:36 libm.a
lrwxrwxrwx 1 pk pk       9 Oct 29 22:36 libm.so -> libm.so.0
lrwxrwxrwx 1 pk pk      16 Oct 29 22:36 libm.so.0 -> libm-0.9.33.2.so
lrwxrwxrwx 1 pk pk       6 Oct 29 22:36 libm_pic.a -> libm.a
-rwxr-xr-x 1 pk pk  118968 Oct 29 22:36 libpthread-0.9.33.2.so
-rw-r--r-- 1 pk pk  323372 Oct 29 22:36 libpthread.a
-rwxr-xr-x 1 pk pk     175 Oct 29 22:36 libpthread.so
lrwxrwxrwx 1 pk pk      22 Oct 29 22:36 libpthread.so.0 -> libpthread-0.9.33.2.so
-rw-r--r-- 1 pk pk    1740 Oct 29 22:36 libpthread_nonshared.a
lrwxrwxrwx 1 pk pk      22 Oct 29 22:36 libpthread_nonshared_pic.a -> libpthread_nonshared.a
-rw-r--r-- 1 pk pk  332842 Oct 29 22:36 libpthread_pic.a
-rwxr-xr-x 1 pk pk   19108 Oct 29 22:36 librt-0.9.33.2.so
-rw-r--r-- 1 pk pk   42208 Oct 29 22:36 librt.a
lrwxrwxrwx 1 pk pk      10 Oct 29 22:36 librt.so -> librt.so.0
lrwxrwxrwx 1 pk pk      17 Oct 29 22:36 librt.so.0 -> librt-0.9.33.2.so
lrwxrwxrwx 1 pk pk       7 Oct 29 22:36 librt_pic.a -> librt.a
-rw-r--r-- 1 pk pk  605610 Oct 30 20:49 libssl.a
lrwxrwxrwx 1 pk pk      15 Oct 30 20:49 libssl.so -> libssl.so.1.0.0
-rwxr-xr-x 1 pk pk  370712 Oct 30 20:49 libssl.so.1.0.0
-rw-r--r-- 1 pk pk 3834270 Oct 29 22:44 libstdc++.a
-rwxr-xr-x 1 pk pk    1061 Oct 29 22:44 libstdc++.la
lrwxrwxrwx 1 pk pk      19 Oct 29 22:44 libstdc++.so -> libstdc++.so.6.0.21
lrwxrwxrwx 1 pk pk      19 Oct 29 22:44 libstdc++.so.6 -> libstdc++.so.6.0.21
-rwxr-xr-x 1 pk pk 1301264 Oct 29 22:44 libstdc++.so.6.0.21
-rw-r--r-- 1 pk pk  584568 Oct 29 22:44 libstdc++fs.a
-rwxr-xr-x 1 pk pk    1001 Oct 29 22:44 libstdc++fs.la
-rw-r--r-- 1 pk pk  286122 Oct 29 22:44 libsupc++.a
-rwxr-xr-x 1 pk pk     995 Oct 29 22:44 libsupc++.la
-rwxr-xr-x 1 pk pk   27872 Oct 29 22:36 libthread_db-0.9.33.2.so
-rw-r--r-- 1 pk pk   81618 Oct 29 22:36 libthread_db.a
lrwxrwxrwx 1 pk pk      17 Oct 29 22:36 libthread_db.so -> libthread_db.so.1
lrwxrwxrwx 1 pk pk      24 Oct 29 22:36 libthread_db.so.1 -> libthread_db-0.9.33.2.so
lrwxrwxrwx 1 pk pk      14 Oct 29 22:36 libthread_db_pic.a -> libthread_db.a
-rw-r--r-- 1 pk pk  492756 Oct 29 22:44 libuClibc++.a
lrwxrwxrwx 1 pk pk      16 Oct 29 22:44 libuClibc++.so -> libuClibc++.so.0
lrwxrwxrwx 1 pk pk      20 Oct 29 22:44 libuClibc++.so.0 -> libuClibc++.so.0.2.5
-rwxr-xr-x 1 pk pk  241964 Oct 29 22:44 libuClibc++.so.0.2.5
-rwxr-xr-x 1 pk pk  731584 Oct 29 22:36 libuClibc-0.9.33.2.so
-rwxr-xr-x 1 pk pk    6680 Oct 29 22:36 libubacktrace-0.9.33.2.so
-rw-r--r-- 1 pk pk    7568 Oct 29 22:36 libubacktrace.a
lrwxrwxrwx 1 pk pk      18 Oct 29 22:36 libubacktrace.so -> libubacktrace.so.0
lrwxrwxrwx 1 pk pk      25 Oct 29 22:36 libubacktrace.so.0 -> libubacktrace-0.9.33.2.so
lrwxrwxrwx 1 pk pk      15 Oct 29 22:36 libubacktrace_pic.a -> libubacktrace.a
-rwxr-xr-x 1 pk pk   11252 Oct 29 22:36 libutil-0.9.33.2.so
-rw-r--r-- 1 pk pk   12320 Oct 29 22:36 libutil.a
lrwxrwxrwx 1 pk pk      12 Oct 29 22:36 libutil.so -> libutil.so.0
lrwxrwxrwx 1 pk pk      19 Oct 29 22:36 libutil.so.0 -> libutil-0.9.33.2.so
lrwxrwxrwx 1 pk pk       9 Oct 29 22:36 libutil_pic.a -> libutil.a
lrwxrwxrwx 1 pk pk      18 Oct 29 22:51 libyaml-0.so.2 -> libyaml-0.so.2.0.2
-rwxr-xr-x 1 pk pk  121920 Oct 29 22:51 libyaml-0.so.2.0.2
-rw-r--r-- 1 pk pk  138976 Oct 29 22:51 libyaml.a
-rwxr-xr-x 1 pk pk    1040 Oct 29 22:51 libyaml.la
lrwxrwxrwx 1 pk pk      18 Oct 29 22:51 libyaml.so -> libyaml-0.so.2.0.2
drwxr-xr-x 1 pk pk      84 Oct 30 20:49 pkgconfig
-rw-r--r-- 1 pk pk    1588 Oct 29 22:36 uclibc_nonshared.a

Aber trotzdem kommt der gleiche Fehler:
Code:
checking for SSL... configure: error: Cannot find the SSL libraries in /home/pk/freetz/toolchain/build/mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/mips-linux-uclibc/lib

ERROR: Build failed.
make/getdns/getdns.mk:21: recipe for target 'source/target-mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/getdns-1.2.0/.configured' failed
make: *** [source/target-mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/getdns-1.2.0/.configured] Error 1

Ich versteh das nicht.
 
Zuletzt bearbeitet:
Code:
checking for SSL_CTX_set_min_proto_version... (cached) no
checking whether SSL_COMP_get_compression_methods is declared... (cached) yes
checking whether sk_SSL_COMP_pop_free is declared... (cached) yes
checking whether SSL_CTX_set_ecdh_auto is declared... (cached) yes
checking for EVP_PKEY_set_type_str... (cached) yes
checking for EC_KEY_new... (cached) yes
checking if GOST works... maybe

@PeterPawn
bei mir läuft das "configure" Befehl nicht fehlerfrei durch;

Code:
freetz@raspi:~/freetz-trunk$ tail -20 fmake.log
checking for ECDSA_SIG_get0... no
checking for EVP_MD_CTX_new... no
checking for EVP_PKEY_base_id... yes
checking for HMAC_CTX_new... no
checking for HMAC_CTX_free... no
checking for TLS_client_method... no
checking for DSA_SIG_set0... no
checking for EVP_dss1... yes
checking for EVP_DigestVerify... no
checking for SSL_CTX_set_min_proto_version... no
checking whether SSL_COMP_get_compression_methods is declared... yes
checking whether sk_SSL_COMP_pop_free is declared... yes
checking whether SSL_CTX_set_ecdh_auto is declared... yes
checking for EVP_PKEY_set_type_str... yes
checking for EC_KEY_new... no
configure: error: OpenSSL does not support ECC, needed for GOST support

ERROR: Build failed.
make/getdns/getdns.mk:20: recipe for target 'source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl_kernel-3.10/getdns-1.2.0/.configured' failed
make: *** [source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl_kernel-3.10/getdns-1.2.0/.configured] Error 1
freetz@raspi:~/freetz-trunk$

Kann mir jemand einen Tipp geben, was hier zu tun ist, damit die getdns Package-Erstellung funktioniert ?

//edit stoney in [CODE] Tag [/CODE] gepackt
 

Anhänge

  • getdns_configure_log.zip
    14 KB · Aufrufe: 1
Zuletzt bearbeitet von einem Moderator:
Sollte der Pfad, wo er die libopenssl sucht nicht sein: "/home/pk/freetz/toolchain/build/mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/mips-linux-uclibc/lib"?

Bitte gib mal "make openssl-dirclean" und dann "./fmake -c getdns-precompiled" ein.
wie üblich fmake.log anhängen.
 
Aktiviere mal zusätzlich die EC-Unterstützung für OpenSSL (FREETZ_LIB_libcrypto_WITH_EC) ... ich hatte "make oldconfig" gemacht nach dem Hinzufügen des neuen Pakets und dabei - anders als bei "make menuconfig" - wird ja einzeln abgefragt. Dabei hatte ich dann EC mit ausgewählt.

EDIT: Oder schalte den GOST-Support mit "--disable-gost" beim "configure" ab ... sollte auch gehen (nur aus der Ansicht der "configure.ac" geschlossen).
 
Die EC habe ich eh dabei, hier das fmake.log nach dem dirclean.
 

Anhänge

  • fmake.log.txt
    568.1 KB · Aufrufe: 3
Ach so ... ich hatte das tatsächlich mit einem frischen Checkout des Freetz-Trunk (original, nicht mal mein Fork) unter x86 mit der allseits bekannten Freetz-VM getestet ... spätestens beim RasPi kommt da wohl die eigene Toolchain (ggf. mit eigener "site configuration" für den Build-Target?) ins Spiel und auch ein "Kali" würde ich jetzt nicht als präferierten Build-Host verwenden.

Mit "Kali" habe ich mich (iirc) erst letztens "herumgeschlagen", als irgendjemand meine YourFritz-Skripte und die bereitgestellten Binaries für x86 unbedingt unter "Kali" für x64 benutzen wollte. Das benutze ich normalerweise wirklich nur für Pentests.
 
Die restlichen Pakete haben in der Umgebung bisher keine Probleme gemacht, ist ja letztlich auch nix anderes als ein etwas dickeres Debian... Baue damit seit Jahren mein Freetz, weil ich nur die eine Distro auf den Desktops habe. (Hatte ja auch mal einen Guide gepostet hier im Forum, wie man alles auf der Kali zum laufen bringt. Sowohl komplette Deps bauen für die ganz alte Kali Version als auch die relevanten Packages installieren in der neuen.) Wo würde ich denn diese etwaig abweichende "site config" finden? Oder ist das System wieder so custom, dass es eigentlich keinen Sinn ergibt, zu versuchen das auf Baseline zu bekommen?
 
Oder schalte den GOST-Support mit "--disable-gost" beim "configure" ab ... sollte auch gehen (nur aus der Ansicht der "configure.ac" geschlossen).

Danke!!!
das war die Lösung.
Code:
freetz@raspi:~/freetz-trunk$ diff make/getdns/getdns.mk.pp make/getdns/getdns.mk
7a8,9
> $(PKG)_CONFIGURE_OPTIONS += --disable-gost
> $(PKG)_CONFIGURE_OPTIONS += --disable-ecdsa
freetz@raspi:~/freetz-trunk$
anschließend ist der "make"-Befehl durchgelaufen.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.