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" (
) 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:
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".
