[Frage] "getdns"-Paket

[PeterPawn]

Bestimmte Einstellungen lassen sich beim Cross-Build nun mal nicht per "configure" automatisch ermitteln ... dafür gibt es vordefinierte Templates, die man verwenden kann, um Einstellungen für das Zielsystem zu setzen. Ich empfehle einen Blick in die entsprechenden Dokumentationen: https://www.gnu.org/software/autoconf/manual/autoconf-2.68/html_node/Site-Defaults.html

Wenn man sich dann mal den "configure"-Aufruf von Freetz anschaut, findet man dort z.B. Werte wie

PKG_CONFIG_PATH="/home/freetz/freetz/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl_kernel-3.10/mips-linux-uclibc/bin/../lib/pkgconfig"
PKG_CONFIG_LIBDIR="/home/freetz/freetz/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl_kernel-3.10/mips-linux-uclibc/bin/../lib/pkgconfig"
GLOBAL_LIBDIR=/home/freetz/freetz/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl_kernel-3.10/mips-linux-uclibc/usr/lib
CONFIG_SITE=/home/freetz/freetz/include/site/mips-linux-uclibc
conf_cmd  <== das ist der eigentliche "configure"-Aufruf
--cache-file=/home/freetz/freetz/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl_kernel-3.10/config.cache
--target=mips-linux
--host=mips-linux
--build=i386-pc-linux-gnu
--program-prefix=""
--program-suffix=""
--prefix=/usr
--exec-prefix=/usr
--bindir=/usr/bin
--datadir=/usr/share
--includedir=/usr/include
--infodir=/usr/share/info
--libdir=/usr/lib
--libexecdir=/usr/lib
--localstatedir=/var
--mandir=/usr/share/man
--sbindir=/usr/sbin
--sysconfdir=/etc
--with-gnu-ld
--disable-nls

Woher kommen die wohl bzw. wohin zeigen deren Pfade eigentlich?

Was da bei Euch jeweils verwendet wird, kann man/ich natürlich nicht sehen, wenn auch die Build-Protokolle dermaßen "geheim" sind (merke: Nicht immer ist Datensparsamkeit angebracht.), daß da die "configure"-Aufrufe nicht wirklich zu sehen sind.

Immerhin scheint die Toolchain aber bei @tuxedonet schon mal die OpenSSL-Installation zu finden, sonst wäre der Fehler mit der fehlenden GOST-Unterstützung gar nicht erst aufgetreten, weil früher abgebrochen würde.

@zyrill:
Warum Du jetzt den SSL-Path auf das "lib"-Verzeichnis im Staging-Bereich legen willst, verstehe ich gar nicht mehr ... Du weißt schon, was "configure" eigentlich macht? Wenn nicht, würde ich wieder den o.a. Link (halt einige Ebenen höher) empfehlen.

Da wird gar nicht nach den fertigen Bibliotheken gesucht, wenn es

Cannot find the SSL libraries in /usr/local/ssl /usr/lib/ssl /usr/ssl /usr/pkg /usr/local /opt/local /usr/sfw /usr

heißt (also interessiert es keinen, wo diese Dateien am Ende liegen), sondern nach den notwendigen Include-Files. Diese automatische Konfiguration übersetzt jeweils kleine Programmschnipsel und versucht über die dabei auftretenden Fehler festzustellen, welche Funktionen das jeweilige System nun unterstützt und welche nicht. Daraus wird dann eine passende Konfiguration gebaut (die getroffenen Feststellungen werden parallel dazu noch in einer Cache-Datei gespeichert, damit nicht jedesmal aufs Neue alles komplett getestet werden muß - daher gibt es auch beim "configure" hinter einigen Einträgen ein "cached" zu sehen) und mit der kann man das Paket dann übersetzen.

Wenn ich mich an ein neues Paket wagen würde, würde ich das zunächst mal in einer Umgebung machen, von der ich definitiv weiß, daß sie funktioniert ... dazu würde Dein "Kali" für mich jetzt nicht direkt gehören, zumal da eigentlich eine eher strikte Trennung zwischen 64-Bit- und 32-Bit-System besteht. Ich hoffe mal, daß Du wenigstens die 32-Bit-Version verwendest ... aber ich habe auch keine wirkliche Lust, da jetzt nach dem Grund zu suchen, wieso es bei Dir offenbar "nicht tut".

Wenn ich das richtig verstanden habe, kriegt @tuxedonet mit der zusätzlichen Konfiguration (also mit "--disable-gost" und dem Abschalten der ECC-Unterstützung in der "libcrypto") das ebenfalls übersetzt ... auch auf einem RasPi(?) und damit in einer ARM-basierten Toolchain. Wenn das stimmt (und selbst wenn nicht, nimm einfach erst mal eine Freetz-VM, da weißt Du dann wenigstens, daß die Umgebung für den Build-Host stimmt, wenn Du Dein erstes eigenes Paket baust), dann funktioniert es ja schon mal bei zweien und damit sinkt die Wahrscheinlichkeit, daß es an einer "Besonderheit" bei mir liegt, wenn es sich zumindest übersetzen läßt.

PS: Es ist bei mir - wie geschrieben - einfach eine Freetz-VM (auf 14.04 gebracht und mit aktuellen Paketen versorgt) ... man erkennt es auch an den Pfaden. Der Trunk wurde in ein Verzeichnis "freetz" ausgecheckt, das "/home/freetz" ist das Home-Verzeichnis des Benutzers "freetz".

 

[tuxedonet]

Könntest Du Bitte die Datei "/home/pk/freetz/toolchain/build/mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/mips-linux-uclibc/getdns-1.2.0/config.log" beifügen.

Ansonsten wie PeterPawn schreibt saubere Build-/OS-Umgebung (Umgebungsvariablen der Freetz-Umgebung, ...), den Trunk neu auschecken, getdns.zip von PeterPawn und "make menuconfig" mit Download-Toolchain verwenden.

freetz@raspi:~/freetz-trunk$ grep -i toolchain .config
SNIP
FREETZ_DOWNLOAD_TOOLCHAIN=y
# FREETZ_BUILD_TOOLCHAIN=n
SNIP
freetz@raspi:~/freetz-trunk$

im Problemfall die für Freetz zum Troubleshooting üblichen Daten:
o .config
o fmake.log
o <SRC_DIR>/getdns-1.2.0/config.log
beifügen.

ein etwas dickeres Debian

auch ist diese Betriebssystem-Angabe wunderbar präzise ;-)
mittels beigefügtem "lsb_release -a" kann Licht ins Dunkel gebraucht werden und ein "Raten" entfällt.

Wo würde ich denn diese etwaig abweichende "site config" finden?

siehe:

grep CONFIG_SITE fmake.log
CONFIG_SITE=/home/pk/freetz/include/site/mips-linux-uclibc

einfach mal Blick in die darin enthaltenen Config-Dateien werfen.

//edit by stoney
### - 5.10 Keine Aneinanderreihung eigener Beiträge (auch "Schieben" genannt) innerhalb von 24 Stunden; hier ist die "Bearbeiten"-Funktion zu verwenden. ###

 

[PeterPawn]

Nur noch mal zur Erinnerung ... die "getdns.zip" erstellt noch kein funktionierendes "getdns"-Paket.

Zwar klappt die Übersetzung und es entsteht auch ein (dynamisch gelinktes) "stubby"-Binary ... da hier mit "libtool" gelinkt wird, steht am Ende im "src"-Verzeichnis nur das entsprechende Wrapper-Skript (ein Shell-Skript), während die notwendigen Object-Files in "src/.libs" stehen und dort gibt es auch eine erste gelinkte Version von "stubby".

Die braucht aber eben noch (neben der "libyaml.so", die ggf. von der Toolchain installiert wird, wenn "FREETZ_LIB_libyaml" gesetzt ist) zusätzlich die erzeugte "libgetdns.so", wenn man sie so linken läßt, wie es von den Autoren vorgesehen ist.

Da man mit den "uninstall"- bzw. "install"-Targets im "Makefile" für das Paket unter den Bedingungen der Toolchain nicht wirklich etwas anfangen kann:

install-headers: getdns/getdns.h getdns/getdns_extra.h
        $(INSTALL) -m 755 -d $(DESTDIR)$(includedir)
        $(INSTALL) -m 755 -d $(DESTDIR)$(includedir)/getdns
        $(INSTALL) -m 644 getdns/getdns.h $(DESTDIR)$(includedir)/getdns/getdns.h
        $(INSTALL) -m 644 getdns/getdns_extra.h $(DESTDIR)$(includedir)/getdns/getdns_extra.h
        if test $(have_libevent) = 1 ; then $(INSTALL) -m 644 $(srcdir)/getdns/getdns_ext_libevent.h $(DESTDIR)$(includedir)/getdns/ ; fi
        if test $(have_libuv) = 1 ; then $(INSTALL) -m 644 $(srcdir)/getdns/getdns_ext_libuv.h $(DESTDIR)$(includedir)/getdns/ ; fi
        if test $(have_libev) = 1 ; then $(INSTALL) -m 644 $(srcdir)/getdns/getdns_ext_libev.h $(DESTDIR)$(includedir)/getdns/ ; fi

uninstall-headers:
        rm -rf $(DESTDIR)$(includedir)/getdns

install-libs: libgetdns.la
        $(INSTALL) -m 755 -d $(DESTDIR)$(libdir)
        $(LIBTOOL) --mode=install cp libgetdns.la $(DESTDIR)$(libdir)
        if test $(have_libevent) = 1 ; then $(LIBTOOL) --mode=install cp $(EXTENSION_LIBEVENT_LIB) $(DESTDIR)$(libdir) ; fi
        if test $(have_libuv) = 1 ; then $(LIBTOOL) --mode=install cp $(EXTENSION_LIBUV_LIB) $(DESTDIR)$(libdir) ; fi
        if test $(have_libev) = 1 ; then $(LIBTOOL) --mode=install cp $(EXTENSION_LIBEV_LIB) $(DESTDIR)$(libdir) ; fi
        $(LIBTOOL) --mode=finish $(DESTDIR)$(libdir)

uninstall-libs:
        if test $(have_libevent) = 1; then $(LIBTOOL) --mode=uninstall rm -f $(DESTDIR)$(libdir)/$(EXTENSION_LIBEVENT_LIB) ; fi
        if test $(have_libuv) = 1; then $(LIBTOOL) --mode=uninstall rm -f $(DESTDIR)$(libdir)/$(EXTENSION_LIBUV_LIB) ; fi
        if test $(have_libev) = 1; then $(LIBTOOL) --mode=uninstall rm -f $(DESTDIR)$(libdir)/$(EXTENSION_LIBEV_LIB) ; fi
        $(LIBTOOL) --mode=uninstall rm -f $(DESTDIR)$(libdir)/libgetdns.la

install: install-libs install-headers install-stubby

uninstall: uninstall-stubby uninstall-headers uninstall-libs

, muß man das eben "von Hand" in der "getdns.mk" machen und für Binaries oder Libraries gibt es ja passende Makros zum Installieren. Jedenfalls steht auch eine passende "libgetdns.so" (Version 6.2.0) in "src/.libs" und man kann das - zum ersten Test - auch alles komplett von Hand kopieren (dabei den Symlink "libgetdns.so.6" nicht vergessen, denn dieser Name wird von "stubby" verwendet beim Laden - bzw. natürlich vom Loader aus der uClibc anhand der Angaben im Binary gesucht) auf die Box.

Ruft man das dann mit den richtigen Einstellungen auf (hier ist das "LD_LIBRARY_PATH=." notwendig, damit das aktuelle Verzeichnis auf der Box auch nach Bibliotheken durchsucht wird), gibt es schon mal den passenden "usage screen":

root@FB7490:/var/media/ftp $ ldd ./stubby
        libyaml-0.so.2 => not found
        libgetdns.so.6 => not found
        libc.so.0 => /lib/libc.so.0 (0x76f94000)
        ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x7704a000)
root@FB7490:/var/media/ftp $ LD_LIBRARY_PATH=. ./stubby -h
usage: stubby [<option> ...] \
        -C      <filename>
                Read settings from config file <filename>
                The getdns context will be configured with these settings
                The file should be in YAML format with an extension of .yml.
                (The old JSON dict format (.conf) is also still supported when
                specified on the command line.)
                By default, the configuration file location is obtained
                by looking for YAML files in the following order:
                        "/var/media/ftp/root/.stubby.yml"
                        "/etc/stubby/stubby.yml"
                An default file (Using Strict mode) is installed as
                        "/etc/stubby/stubby.yml"
        -g      Run stubby in background (default is foreground)
        -h      Print this help
        -i      Validate and print the configuration only. Useful to validate config file contents.
        -l      Enable logging of all logs (same as -v 7)
        -v      Specify logging level (overrides -l option). Values are
                        0: EMERG  - System is unusable
                        1: ALERT  - Action must be taken immediately
                        2: CRIT   - Critical conditions
                        3: ERROR  - Error conditions
                        4: WARN   - Warning conditions
                        5: NOTICE - Normal, but significant, condition
                        6: INFO   - Informational message
                        7: DEBUG  - Debug-level message
root@FB7490:/var/media/ftp $

, wobei die "libyaml.so" entweder schon im SquashFS sein muß oder ebenfalls ins aktuelle Verzeichnis auf der Box zu kopieren wäre (wie bei mir zum Test).

 

[tuxedonet]

folgendes ist mir aufgefallen:
1.) es wird der Cross-Compiler für die Kernel Sourcen statt Cross-Compiler für User-Space progs verwendet.
siehe fmake.log.txt/openssl-precompiled.log aus #10

fmake.log.txt:
SNIP
PATH="/home/pk/freetz-devel/toolchain/build/mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/mips-linux-uclibc/bin:/home/pk/freetz-devel/toolchain/build/mips_gcc-4.8.5/mips-unknown-linux-gnu/bin:/us
FREETZ_LIBRARY_DIR="/usr/lib/freetz"
make  "$@"  || { printf "\n\\033[33m%s\\033[m\n" "ERROR: Build failed.";  exit 1; } };
if [ -e source/.echo_item_start -a ! -e source/.echo_item_build ]; then echo -n "building... "; touch source/.echo_item_build; fi;
cmd -C source/target-mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/openssl-1.0.2l
MAKEDEPPROG="/home/pk/freetz-devel/toolchain/build/mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/mips-linux-uclibc/bin/mips-linux-uclibc-gcc"
CC="/home/pk/freetz-devel/toolchain/build/mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/mips-linux-uclibc/bin/mips-linux-uclibc-gcc"
AR="/home/pk/freetz-devel/toolchain/build/mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/mips-linux-uclibc/bin/mips-linux-uclibc-ar r"
RANLIB="/home/pk/freetz-devel/toolchain/build/mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/mips-linux-uclibc/bin/mips-linux-uclibc-ranlib"
NM="/home/pk/freetz-devel/toolchain/build/mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/mips-linux-uclibc/bin/mips-linux-uclibc-nm"
FREETZ_MOD_OPTIMIZATION_FLAGS="-march=24kc -mtune=24kc -msoft-float -Os -pipe -Wa,--trap -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -ffunction-sections -fdata-sections"
SHARED_LDFLAGS="" INSTALL_PREFIX="/home/pk/freetz-devel/toolchain/build/mips_gcc-5.4.0_uClibc-0.9.33.2-nptl_kernel-3.10/mips-linux-uclibc" CROSS_COMPILE=1  $target; \
done

Ist das so richtig ?
bzw. was ist ggf. zu tun, um auf User-Space-Cross-Compiler umzustellen ?

2.)

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?

cat getdns-1.2.0/README.md
SNIP
For example, to build on a recent version of Ubuntu, you would need the following packages:
    # apt install build-essential libunbound-dev libidn11-dev libssl-dev libtool m4 autoconf

@zrill: war hier evtl. das Debian-Package "libssl-dev" oder "libopenssl-dev" VOR dem Erstellen der Toolchain installiert ? Kontrolle "dpkg -l | grep ssl-dev" durchführen

Hierzu gibt es einen Hinweis in openssl.mk Datei

cat make/openssl/openssl.mk
SNIP
$($(PKG)_BINARY_BUILD_DIR) $($(PKG)_LIBS_BUILD_DIR): $($(PKG)_DIR)/.configured
#       OpenSSL's "make depend" looks for installed headers before its own,
#       so remove installed stuff from the staging dir first.
#       Remove installed libs also from freetz' packages dir to ensure
#       that it doesn't contain files from previous builds (0.9.8 to/from 1.0.x switch).
        $(MAKE) openssl-clean-staging openssl-uninstall
        for target in depend all; do \
                $(SUBMAKE1) $(OPENSSL_MAKE_FLAGS) $$target; \
        done

Ist das so richtig ?
bzw. kann dies die Ursache des Problems sein ?

kann hier jemand Tipps geben ?

 

[zyrill]

Ich habe nochmal neu angefangen wegen des Hinweises, dass eine 64bit Kali Distribution evtl. zusätzliche Komplexität in den Buildprozess einbringt. Habe also das FreetzVM Image heruntergeladen (v1.4.1), aktualisiert, Freetz ausgecheckt, Deps gefixt und dann den Build Prozess gestartet mit:

sudo apt-get update
sudo apt-get upgrade -y
sudo apt-get dist-upgrade -y
sudo apt-get autoremove -y
do-release-upgrade
git clone https://github.com/Freetz/freetz.git
sudo ln -s /usr/bin/libtoolize /usr/bin/libtool 
sudo apt-get install libreadline-dev
make menuconfig
make

Also hier nochmal die geforderte Info:

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.3 LTS
Release:        16.04
Codename:       xenial

Und

freetz@freetz-linux:~/freetz$ dpkg -l | grep ssl-dev
freetz@freetz-linux:~/freetz$

Dann hab ich die getdns.zip von PeterPawn genommen, habe nochmal make openssl-dirclean ausgeführt und hänge wieder beim selben Ergebnis: SSL Libs werden nicht gefunden. Anbei die 3 gewünschten Debugdateien.

Ich habe verstanden, dass configure dafür sorgt, dass die richtigen Compiler, Linker etc. für das jeweilige Projekt genutzt werden und entsprechende Pfade bereitstellt. Wo würde ich denn überprüfen, welche Pfade (für die SSL Libs) übergeben werden?

 

[PeterPawn]

OK, "getdns" kommt mit einer eigenen Version des OpenSSL-Checks, zu finden in "m4/acx_openssl.m4".

Damit führt dann das Fehlen des "ssl-dev"-Pakets auf dem Build-Host dazu, daß dort die Autokonfiguration fehlschlägt (bei der Übersetzung würde er dann wieder die richtigen Dateien finden) und man kann nun entweder tatsächlich mittels "--with-ssl" den Pfad dorthin angeben (dann aber ohne "include", wie man hier sehen kann in der "acx_openssl.m4"):

        for dir in $withval; do
            ssldir="$dir"
            if test -f "$dir/include/openssl/ssl.h"; then
                found_ssl="yes"
                AC_DEFINE_UNQUOTED([HAVE_SSL], [], [Define if you have the SSL libraries installed.])
                dnl assume /usr/include is already in the include-path.
                if test "$ssldir" != "/usr"; then
                        CPPFLAGS="$CPPFLAGS -I$ssldir/include"
                        LIBSSL_CPPFLAGS="$LIBSSL_CPPFLAGS -I$ssldir/include"
                fi
                break;
            fi
        done

(also mit einer zusätzlichen Zeile "$(PKG)_CONFIGURE_OPTIONS += --with-ssl=$(TARGET_TOOLCHAIN_STAGING_DIR)") oder auf dem Build-Host dafür sorgen, daß dieser selbstgemachte OpenSSL-Test von "getdns" am Ende die Host-Dateien findet ... der Rest sollte dann auch wieder problemlos funktionieren, denn der Compiler müßte die richtigen Dateien verwenden und nur dieses "test"-Kommando im m4-Makro sucht halt an der falschen Stelle. Sind die Dateien auf dem Host vorhanden, fällt das nicht weiter auf ... aber hier hilft am Ende nicht einmal ein zuvor bereits mit OpenSSL gebautes anderes Paket, weil die Einstellungen für den Test am Beginn von "ACX_SSL_CHECKS" wohl gar nicht aus dem Cache gelesen würden, selbst wenn dort bereits Tests sich verewigt hätten:

$ grep -i ssl config.cache
ac_cv_env_OPENSSL_CFLAGS_set=
ac_cv_env_OPENSSL_CFLAGS_value=
ac_cv_env_OPENSSL_LIBS_set=
ac_cv_env_OPENSSL_LIBS_value=
ac_cv_func_OPENSSL_config=${ac_cv_func_OPENSSL_config=yes}
ac_cv_func_SSL_CTX_get0_param=${ac_cv_func_SSL_CTX_get0_param=yes}
ac_cv_func_SSL_CTX_get_default_passwd_cb=${ac_cv_func_SSL_CTX_get_default_passwd_cb=no}
ac_cv_func_SSL_CTX_get_default_passwd_cb_userdata=${ac_cv_func_SSL_CTX_get_default_passwd_cb_userdata=no}
ac_cv_func_SSL_CTX_new=${ac_cv_func_SSL_CTX_new=yes}
ac_cv_func_SSL_CTX_set_min_proto_version=${ac_cv_func_SSL_CTX_set_min_proto_version=no}
ac_cv_have_decl_SSL_COMP_get_compression_methods=${ac_cv_have_decl_SSL_COMP_get_compression_methods=yes}
ac_cv_have_decl_SSL_CTX_set_ecdh_auto=${ac_cv_have_decl_SSL_CTX_set_ecdh_auto=yes}
ac_cv_have_decl_sk_SSL_COMP_pop_free=${ac_cv_have_decl_sk_SSL_COMP_pop_free=yes}
ac_cv_header_openssl_bio_h=${ac_cv_header_openssl_bio_h=yes}
ac_cv_header_openssl_bn_h=${ac_cv_header_openssl_bn_h=yes}
ac_cv_header_openssl_conf_h=${ac_cv_header_openssl_conf_h=yes}
ac_cv_header_openssl_dsa_h=${ac_cv_header_openssl_dsa_h=yes}
ac_cv_header_openssl_engine_h=${ac_cv_header_openssl_engine_h=yes}
ac_cv_header_openssl_err_h=${ac_cv_header_openssl_err_h=yes}
ac_cv_header_openssl_rand_h=${ac_cv_header_openssl_rand_h=yes}
ac_cv_header_openssl_rsa_h=${ac_cv_header_openssl_rsa_h=yes}
ac_cv_header_openssl_ssl_h=${ac_cv_header_openssl_ssl_h=yes}
sc_cv_have_libssl=${sc_cv_have_libssl=yes}
sc_cv_have_openssl_ssl_h=${sc_cv_have_openssl_ssl_h=yes}
sv_cv_have_openssl_fips_h=${sv_cv_have_openssl_fips_h=no}

Damit sollte er dann die OpenSSL-Header auch finden können ... man sieht ja weiter oben, daß er in Wirklichkeit nach der "ssl.h" sucht.

 

[zyrill]

Ahaaa! Abhängigkeit verstanden. D.h. für eine saubere Lösung müsste der SSL Check entweder herausgepatcht werden (unter der Prämisse, dass mit "$(PKG)_DEPENDS_ON += openssl" die Voraussetzung geschaffen ist - aber irgendwie hässlich) oder der SSL Check müsste gepatcht werden, dass er tatsächlich bei der korrekten Toolchain in den includes nachschaut. Und außerdem muss das Makefile angepasst werden, sodass entweder statisch gelinkt oder die libs ins Verzeichnis kopiert werden.

Ich habe etwas weiter gebastelt und verstehe offensichtlich die Makefile Syntax falsch. Ich habe in der getdns.mk folgende Zeilen hinzugefügt:

7a8,11
> $(PKG)_LIB_GETDNS := libgetdns.so.6.2.0
> $(PKG)_LIB_GETDNS_BUILD_DIR := $($(PKG)_LIB_GETDNS:%=$($(PKG)_DIR)/src/.libs/%)
> $(PKG)_LIB_GETDNS_TARGET_DIR := $($(PKG)_LIB_GETDNS:%=$($(PKG)_DEST_LIBDIR)/%)
>
27a32,33
> $($(PKG)_LIB_GETDNS_TARGET_DIR): $($(PKG)_DEST_LIBDIR)/%: $($(PKG)_DIR)/src/.libs/%
>       $(INSTALL_LIBRARY_STRIP)

Und dachte, damit müsste die libgetdns.so.6.2.0 nach /lib installiert werden, aber stattdessen taucht die libgetdns gar nicht auf auf der Box. Ich habe die Zeilen bei imagemagick abgeschaut - da machen die das genau so mit der libmagickcore.so. Was mach ich falsch?

 

[tuxedonet]

Und dachte, damit müsste die libgetdns.so.6.2.0 nach /lib installiert werden, aber stattdessen taucht die libgetdns gar nicht auf auf der Box. Ich habe die Zeilen bei imagemagick abgeschaut - da machen die das genau so mit der libmagickcore.so.

in welcher Rule ist das Target "$($(PKG)_LIB_GETDNS_TARGET_DIR): " als Abhängigkeit definiert ?
das sollte IMHO wie bei "imagemagick.mk" in die Rule "$(pkg)-precompiled: " aufgeommen werden.

 

[zyrill]

Danke, genau das wars. Eine Frage noch: stubby findet die libyaml-0.so.2 nicht, allerdings liegt die - wie auch die libgetdns.so.6 in /usr/lib/freetz (die stubby auch nicht findet). Was mache ich falsch?

root@fritz:/var/mod/root# ldd /usr/sbin/stubby
        libyaml-0.so.2 => not found
        libgetdns.so.6 => not found
        libc.so.0 => /lib/libc.so.0 (0x77e17000)
        ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x77eae000)

Und

root@fritz:/var/mod/root# export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/freetz"

bringt auch nix.

Edit: ah, aber mit

LD_LIBRARY_PATH=/usr/lib/freetz /usr/sbin/stubby

gehts!

 

[tuxedonet]

Edit: ah, aber mit

LD_LIBRARY_PATH=/usr/lib/freetz /usr/sbin/stubby

gehts!

ich könnte mir vorstellen, dass RPATH "verbogen" ist:

Bitte prüfen:

root@fritz:/var/mod/root# readelf -d /usr/sbin/stubby | grep RPATH

wenn alles OK ist, dann erscheint "Library rpath: [/usr/lib/freetz]":

freetz@rpi2:~/freetz-trunk$ ./source/toolchain-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl_kernel-3.10/binutils-2.24-build/binutils/readelf -d ./source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl_kernel-3.10/busybox-1.27.2/busybox

Dynamic section at offset 0x148 contains 27 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libc.so.0]
 0x0000000f (RPATH)                      Library rpath: [/usr/lib/freetz]
SNIP
freetz@rpi2:~/freetz-trunk$

 

[zyrill]

Ahja, danke für den Tipp, das wars. Jetzt passts:

freetz@freetz-linux:~/freetz$ readelf -d build/modified/filesystem/usr/sbin/stubby | grep RPATH
 0x0000000f (RPATH)                      Bibliothek rpath: [/usr/lib/freetz]

Meine getdns.mk schaut jetzt so aus:

$(call PKG_INIT_BIN, 1.2.1)
$(PKG)_SOURCE:=getdns-$($(PKG)_VERSION).tar.gz
$(PKG)_SOURCE_MD5:=34c3633d612df7a80873804120344e3a
$(PKG)_SITE:=https://getdnsapi.net/releases/getdns-1-2-1
$(PKG)_BINARY:=$($(PKG)_DIR)/src/.libs/stubby
$(PKG)_TARGET_BINARY:=$($(PKG)_DEST_DIR)/usr/sbin/stubby

$(PKG)_LIB_GETDNS := libgetdns.so.6.2.1
$(PKG)_LIB_GETDNS_BUILD_DIR := $($(PKG)_LIB_GETDNS:%=$($(PKG)_DIR)/src/.libs/%)
$(PKG)_LIB_GETDNS_TARGET_DIR := $($(PKG)_LIB_GETDNS:%=$($(PKG)_DEST_LIBDIR)/%)

$(PKG)_CONFIGURE_OPTIONS += --without-libidn
$(PKG)_CONFIGURE_OPTIONS += --enable-stub-only
$(PKG)_CONFIGURE_OPTIONS += --with-stubby
$(PKG)_CONFIGURE_OPTIONS += --srcdir=$(FREETZ_BASE_DIR)/$($(PKG)_DIR)
$(PKG)_CONFIGURE_OPTIONS += --with-ssl=$(TARGET_TOOLCHAIN_STAGING_DIR)
$(PKG)_CONFIGURE_OPTIONS += --disable-rpath

$(PKG)_EXTRA_CFLAGS += -std=gnu99

$(PKG)_DEPENDS_ON += openssl
$(PKG)_DEPENDS_ON += yaml

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

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

$($(PKG)_TARGET_BINARY): $($(PKG)_BINARY)
        $(INSTALL_BINARY_STRIP)
$($(PKG)_LIB_GETDNS_TARGET_DIR): $($(PKG)_DEST_LIBDIR)/%: $($(PKG)_DIR)/src/.libs/%
        $(INSTALL_LIBRARY_STRIP)

$(pkg):

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

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

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

$(PKG_FINISH)

 

[tuxedonet]

Und

root@fritz:/var/mod/root# export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/freetz"

bringt auch nix.

Hinweis: eigentlich sollte #29 mit
"export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/lib/freetz;
ldd /usr/sbin/stubby"
auch funktionieren;

nun fehlt nur noch die getdns.mk mit den Features:
static
external
sowie die Separierung von libgetdns,
dann könnte ich mir vorstellen, dass dieser Patch bei Freetz-Developers eingereicht werden kann;-)

 

[PeterPawn]

Wenn "libgetdns" gar nicht separiert wird, sondern man "stubby" gegen diese (und ggf. gegen die "libyaml" noch, die ist auch eher klein und wird selten benötigt) statisch linkt, braucht man auch nur über "externals" für "stubby" nachzudenken und kann auf die Behandlung der "libgetdns" verzichten. Solange es kein zweites Paket gibt, welches von der "libgetdns" als DSO profitieren kann (und Freetz nun mal keinen dynamischen Austausch einer Library kennt, das wäre sonst ein weiterer Punkt, der für die DSO-Verwendung sprechen könnte), braucht es nur unnötigen Aufwand beim Laden, wenn man "libgetdns" dynamisch macht.

Wobei schon noch ein "kleines" Konfigurationsinterface sinnvoll wäre ... das kann ja notfalls (innerhalb des Freetz-GUI) aus der Standard-Datei und nur einem HTML-"textarea" bestehen, in dem die Konfigurationsdatei editiert werden kann. Auch die anderen Dateien (in "files"), die zur Konfiguration von Basiseinstellungen und zur Registrierung des Services erforderlich sind (damit der über's Freetz-GUI verwaltet werden kann), sollte man dann noch hinzufügen, wenn man das als fertiges Paket "anbieten" will.

 

[zyrill]

Streng genommen wäre es doch dann besser, wenn man die libyaml dann auch selbst kompiliert, oder? Sonst liegt da so eine nicht benutzte lib im image rum - oder kann ich das irgendwie verhindern, dass die mitkopiert wird, wenn ich statisch linke? (Wahrscheinlich nicht, aufgrund des Auswählens der lib übers Menü...)

 

[PeterPawn]

Aus dem Kopf ... wenn Du nur die Abhängigkeit in "getdns.mk" mit "$(PKG)_DEPENDS_ON" hinzufügst, müßte das Paket korrekt vor "getdns" erstellt werden und den Teil muß man ja nicht doppelt machen.

Solange Du nicht "FREETZ_LIB_libyaml" in der Konfiguration setzt, müßte diese Library später im Build-Prozess (wenn die Bibliotheken in das "/usr/lib/freetz"-Verzeichnis für's Image kopiert werden - bis dahin liegen die m.E. nur im Staging-Bereich herum) beim Kopieren eigentlich ignoriert werden.

Erstens kann man das ziemlich gut testen (bei entsprechend geschwätzigem "fwmod" müßte das sogar in der Ausgabe zu sehen sein) und zweitens würde ich dann für "libyaml" tatsächlich einen Test ins Makefile für "getdns" einbauen ... wenn "FREETZ_LIB_libyaml" irgendwie definiert ist, wird die auch dynamisch gelinkt (dann hat ein anderes Paket die Library ausgewählt und braucht sie) und ansonsten wird sie statisch zu "stubby" gelinkt.

 

[zyrill]

Hmmm. Wenn ich FREETZ_LIB_libyaml nicht setze, wird die libyaml-0.so.2 dennoch shared gelinked dann aber nicht kopiert - also fehlt sie auf der Box. Sieht dann so aus:

root@fritz:/var/mod/root# ldd /usr/sbin/stubby
        libyaml-0.so.2 => not found
        libssl.so.1.0.0 => /usr/lib/freetz/libssl.so.1.0.0 (0x77eaf000)
        libcrypto.so.1.0.0 => /usr/lib/freetz/libcrypto.so.1.0.0 (0x77d52000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x77d2a000)
        libc.so.0 => /lib/libc.so.0 (0x77c93000)
        libdl.so.0 => /lib/libdl.so.0 (0x77c7f000)
        ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x77f0a000)

 

[PeterPawn]

Das "FREETZ_LIB_libyaml" ist nur dafür verantwortlich, ob die Bibliothek am Ende ins Image kopiert wird oder nicht. Um das Linken und die dafür notwendigen Optionen mußt Du Dich gesondert kümmern. Aber zumindest hat Dein Test ja gezeigt, daß eine nicht gesetzte Einstellung "FREETZ_LIB_libyaml" tatsächlich dazu führt, daß die DSO-Variante der "libyaml" nicht im Image landet.

Wie genau sieht denn jetzt das "Makefile" aus? Hast Du das Linken der "libgetdns" über zusätzliche Flags in "getdns.mk" geändert oder hast Du das "Makefile" in "src" gepatcht? Wenn Du das über die "getdns.mk" gemacht hast, kannst Du ja über die Abfrage, ob "FREETZ_LIB_libyaml" gesetzt ist oder nicht, noch weitere Optionen hinzufügen.

 

[Shirocco88]

Habe mir das getdns auch mit Freetz kompilert und konnte das Fehlerbild "configure: error: OpenSSL does not support ECC, needed for GOST support" aus #14 mit Rasberry-PI2 und Ubuntu-16.04 nachvollziehen:

Aktiviere mal zusätzlich die EC-Unterstützung für OpenSSL (FREETZ_LIB_libcrypto_WITH_EC) ...

Genau, dies sollte gleich als Requirement in Config.in gesetzt werden:

freetz@raspi2:~/freetz-trunk$ diff make/getdns/Config.in.zyrill make/getdns/Config.in
7a8
>       select FREETZ_LIB_libcrypto_WITH_EC

freetz@raspi2:~/freetz-trunk$ cat make/getdns/Config.in
config FREETZ_PACKAGE_GETDNS
        bool "getdns 1.2.1"
        select FREETZ_LIB_libyaml
        select FREETZ_OPENSSL_VERSION_PROMPT
        select FREETZ_OPENSSL_VERSION_1_REQUIRED
        select FREETZ_LIB_libssl
        select FREETZ_LIB_libcrypto
        select FREETZ_LIB_libcrypto_WITH_EC
        default n
        help
                getdns/Stubby is an application that acts as a local DNS
                Privacy stub resolver (using DNS-over-TLS). Stubby encrypts
                DNS queries sent from a client machine (desktop or laptop)
                to a DNS Privacy resolver increasing end user privacy.
freetz@raspi2:~/freetz-trunk$

Oder schalte den GOST-Support mit "--disable-gost"

Alternativ statt "FREETZ_LIB_libcrypto_WITH_EC" können auch "disable-ecdsa" und "disable-gost" gesetzt werden:

freetz@raspi2:~/freetz-trunk$ diff make/getdns/getdns.mk.zyrill make/getdns/getdns.mk
14a15,16
> $(PKG)_CONFIGURE_OPTIONS += --disable-gost
> $(PKG)_CONFIGURE_OPTIONS += --disable-ecdsa
freetz@raspi2:~/freetz-trunk$

neue Dateien als ZIP-File:

 

[zyrill]

Hat einer von Euch stubby nicht nur zum Starten, sondern tatsächlich zum Laufen gebracht? Bei mir treten irgendwelche Fehler wegen fehlender Zertifikate auf... Ich analysiere gerade noch.

 

[PeterPawn]

Ich habe es nicht weiter probiert, ich habe meinen eigenen DNS-Server im Internet stehen und dorthin geht ohnehin schon von allen relevanten Anschlüssen ein VPN-Tunnel ... da braucht's kein TLS für DNS und vor allem keinen "Drittserver", denn auch die Server des "DNS Privacy"-Projekts sind halt strenggenommen solche Punkte, an denen die Überwachung ansetzen kann. Mein DNS-Server wird von genug Clients genutzt, so daß da kein Verkehr mehr einem Einzelnen zugeordnet werden kann.

Vielleicht stellst Du ja mal die betreffenden Fehlermeldungen hier ein ... so rein in Prosa ist das schwer zu beurteilen, was da ggf. wirklich fehlt.