.titleBar { margin-bottom: 5px!important; }

[Frage] "getdns"-Paket

Dieses Thema im Forum "Freetz" wurde erstellt von zyrill, 28 Okt. 2017.

  1. PeterPawn

    PeterPawn IPPF-Promi

    Registriert seit:
    10 Mai 2006
    Beiträge:
    9,728
    Zustimmungen:
    262
    Punkte für Erfolge:
    83
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    #21 PeterPawn, 30 Okt. 2017
    Zuletzt bearbeitet: 30 Okt. 2017
    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
    Code:
    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
    Code:
    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 gefällt das.
  2. tuxedonet

    tuxedonet Neuer User

    Registriert seit:
    20 Sep. 2015
    Beiträge:
    99
    Zustimmungen:
    3
    Punkte für Erfolge:
    8
    #22 tuxedonet, 31 Okt. 2017
    Zuletzt bearbeitet: 31 Okt. 2017
    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.
    Code:
    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.


    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.

    siehe:
    Code:
    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. ###
     
  3. PeterPawn

    PeterPawn IPPF-Promi

    Registriert seit:
    10 Mai 2006
    Beiträge:
    9,728
    Zustimmungen:
    262
    Punkte für Erfolge:
    83
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    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:
    Code:
    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":
    Code:
    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 gefällt das.
  4. tuxedonet

    tuxedonet Neuer User

    Registriert seit:
    20 Sep. 2015
    Beiträge:
    99
    Zustimmungen:
    3
    Punkte für Erfolge:
    8
    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
    Code:
    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.)
    Code:
    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
    Code:
    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 ?
     
  5. zyrill

    zyrill Neuer User

    Registriert seit:
    29 Juli 2009
    Beiträge:
    86
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Ort:
    Frankfurt
    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:
    Code:
    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:
    Code:
    lsb_release -a
    No LSB modules are available.
    Distributor ID: Ubuntu
    Description:    Ubuntu 16.04.3 LTS
    Release:        16.04
    Codename:       xenial
    Und
    Code:
    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?
     

    Anhänge:

  6. PeterPawn

    PeterPawn IPPF-Promi

    Registriert seit:
    10 Mai 2006
    Beiträge:
    9,728
    Zustimmungen:
    262
    Punkte für Erfolge:
    83
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    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"):
    Code:
            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:
    Code:
    $ 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.
     
  7. zyrill

    zyrill Neuer User

    Registriert seit:
    29 Juli 2009
    Beiträge:
    86
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Ort:
    Frankfurt
    #27 zyrill, 8 Nov. 2017
    Zuletzt bearbeitet: 9 Nov. 2017
    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:
    Code:
    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?
     
  8. tuxedonet

    tuxedonet Neuer User

    Registriert seit:
    20 Sep. 2015
    Beiträge:
    99
    Zustimmungen:
    3
    Punkte für Erfolge:
    8
    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.
     
  9. zyrill

    zyrill Neuer User

    Registriert seit:
    29 Juli 2009
    Beiträge:
    86
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Ort:
    Frankfurt
    #29 zyrill, 13 Nov. 2017
    Zuletzt bearbeitet: 13 Nov. 2017
    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?
    Code:
    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
    Code:
    root@fritz:/var/mod/root# export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/freetz" 
    bringt auch nix.

    Edit: ah, aber mit
    Code:
    LD_LIBRARY_PATH=/usr/lib/freetz /usr/sbin/stubby
    gehts! :)
     

    Anhänge:

  10. tuxedonet

    tuxedonet Neuer User

    Registriert seit:
    20 Sep. 2015
    Beiträge:
    99
    Zustimmungen:
    3
    Punkte für Erfolge:
    8
    ich könnte mir vorstellen, dass RPATH "verbogen" ist:

    Bitte prüfen:
    Code:
    root@fritz:/var/mod/root# readelf -d /usr/sbin/stubby | grep RPATH
    wenn alles OK ist, dann erscheint "Library rpath: [/usr/lib/freetz]":
    Code:
    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$
    
     
  11. zyrill

    zyrill Neuer User

    Registriert seit:
    29 Juli 2009
    Beiträge:
    86
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Ort:
    Frankfurt
    Ahja, danke für den Tipp, das wars. Jetzt passts:
    Code:
    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:
    Code:
    $(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)
     
  12. tuxedonet

    tuxedonet Neuer User

    Registriert seit:
    20 Sep. 2015
    Beiträge:
    99
    Zustimmungen:
    3
    Punkte für Erfolge:
    8
    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;-)
     
  13. PeterPawn

    PeterPawn IPPF-Promi

    Registriert seit:
    10 Mai 2006
    Beiträge:
    9,728
    Zustimmungen:
    262
    Punkte für Erfolge:
    83
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    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.
     
  14. zyrill

    zyrill Neuer User

    Registriert seit:
    29 Juli 2009
    Beiträge:
    86
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Ort:
    Frankfurt
    #34 zyrill, 14 Nov. 2017
    Zuletzt bearbeitet: 14 Nov. 2017
    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ü...)
     
  15. PeterPawn

    PeterPawn IPPF-Promi

    Registriert seit:
    10 Mai 2006
    Beiträge:
    9,728
    Zustimmungen:
    262
    Punkte für Erfolge:
    83
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    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.
     
  16. zyrill

    zyrill Neuer User

    Registriert seit:
    29 Juli 2009
    Beiträge:
    86
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Ort:
    Frankfurt
    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:
    Code:
    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)
     
  17. PeterPawn

    PeterPawn IPPF-Promi

    Registriert seit:
    10 Mai 2006
    Beiträge:
    9,728
    Zustimmungen:
    262
    Punkte für Erfolge:
    83
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    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.
     
  18. Shirocco88

    Shirocco88 Mitglied

    Registriert seit:
    4 Jan. 2016
    Beiträge:
    464
    Zustimmungen:
    18
    Punkte für Erfolge:
    18
    #38 Shirocco88, 18 Nov. 2017
    Zuletzt bearbeitet: 18 Nov. 2017
    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:

    Genau, dies sollte gleich als Requirement in Config.in gesetzt werden:
    Code:
    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$ 
    Alternativ statt "FREETZ_LIB_libcrypto_WITH_EC" können auch "disable-ecdsa" und "disable-gost" gesetzt werden:
    Code:
    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:
     

    Anhänge:

  19. zyrill

    zyrill Neuer User

    Registriert seit:
    29 Juli 2009
    Beiträge:
    86
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Ort:
    Frankfurt
    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.
     
  20. PeterPawn

    PeterPawn IPPF-Promi

    Registriert seit:
    10 Mai 2006
    Beiträge:
    9,728
    Zustimmungen:
    262
    Punkte für Erfolge:
    83
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    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.