2017-11-15 1 views
0

TL; DRWie behebe ich einen nicht definierten Verweis auf `nettle_sha256_digest`?

Ich bin versucht, ein Go-Projekt zu erstellen, die diese Abhängigkeit verwendet: https://github.com/mqu/openldap, die wiederum von außen lldap und llber Bibliotheken verknüpft, die wiederum lgnutls verwendet, die lnettle verwendet, die wo ist Ich stecke fest.

Die go build erzeugt eine lange Liste nicht definierter Referenzen und der Build schlägt fehl. Hier ist ein Beispiel:

/usr/lib/x86_64-linux-gnu/libgnutls.a(sha-x86-ssse3.o): In function `_ctx_init': 
(.text+0x468): undefined reference to `nettle_sha256_digest' 
/usr/lib/x86_64-linux-gnu/libgnutls.a(sha-x86-ssse3.o): In function `_ctx_init': 
(.text+0x476): undefined reference to `nettle_sha224_init' 
/usr/lib/x86_64-linux-gnu/libgnutls.a(sha-x86-ssse3.o): In function `_ctx_init': 
(.text+0x494): undefined reference to `nettle_sha256_init' 
/usr/lib/x86_64-linux-gnu/libgnutls.a(sha-x86-ssse3.o): In function `_ctx_init': 
(.text+0x4b8): undefined reference to `nettle_sha256_digest' 
/usr/lib/x86_64-linux-gnu/libgnutls.a(sha-x86-ssse3.o): In function `_ctx_init': 
(.text+0x4c6): undefined reference to `nettle_sha256_init' 
/usr/lib/x86_64-linux-gnu/libgnutls.a(sha-x86-ssse3.o):(.data.rel.ro+0x18): undefined reference to `nettle_sha256_init' 
/usr/lib/x86_64-linux-gnu/libgnutls.a(sha-x86-ssse3.o):(.data.rel.ro+0x28): undefined reference to `nettle_sha256_digest' 
/usr/lib/x86_64-linux-gnu/libgnutls.a(sha-x86-ssse3.o):(.data.rel.ro+0x58): undefined reference to `nettle_sha224_init' 
/usr/lib/x86_64-linux-gnu/libgnutls.a(sha-x86-ssse3.o):(.data.rel.ro+0x68): undefined reference to `nettle_sha224_digest' 
/usr/lib/x86_64-linux-gnu/libgnutls.a(sha-x86-ssse3.o):(.data.rel.ro+0x98): undefined reference to `nettle_sha1_init' 
/usr/lib/x86_64-linux-gnu/libgnutls.a(sha-x86-ssse3.o):(.data.rel.ro+0xa8): undefined reference to `nettle_sha1_digest' 

Und mein go build Befehl:

CC=/usr/local/musl/bin/musl-gcc \ 
    GOOS=linux go build \ 
    -o /bin/activedirectory \ 
    -ldflags '-linkmode external -extldflags "-static -L/usr/lib/x86_64-linux-gnu -lnettle -lp11 -lsasl2 -lgnutls -ltasn1"' 

ich versucht habe, die Lösung dieses durch die Installation von libnettle4, nettle-dev, libghc-nettle-dev, nettle-bin. Ich habe sichergestellt, dass -lnettle in den ldflags enthalten ist. Kein Glück.

Mehr Kontext

Die OpenLDAP-Bibliothek ist die Verknüpfung der ldap und lber Libs im Code:

package openldap 

/* 

#define LDAP_DEPRECATED 1 
#include <stdlib.h> 
#include <ldap.h> 

static inline char* to_charptr(const void* s) { return (char*)s; } 
static inline LDAPControl** to_ldapctrlptr(const void* s) { 
    return (LDAPControl**) s; 
} 
*/ 
// #cgo CFLAGS: -DLDAP_DEPRECATED=1 
// #cgo linux CFLAGS: -DLINUX=1 
// #cgo LDFLAGS: -lldap -llber 

Das bin ich erforderlich ist zu installieren und sind in den ldflags alle Bibliotheken, die Sie sehen in mein Build-Befehl.

So ist die Abhängigkeitskette, kurz gesagt, geht so:

lldap -> lgnutls -> lnettle.

Ich fügte lgnutls hinzu und das löste meine gnutls-Abhängigkeitsprobleme, aber ich bin nicht in der Lage, meine Nessel-Abhängigkeitsprobleme aufzulösen.

Meine Frage

Was bin ich in meinen Versuchen falsch zu machen, diese Nessel Abhängigkeitsprobleme zu beheben?

Bonus Frage

Gibt es eine bewährte Methode, um diese ld Linker Abhängigkeiten für die Lösung? Gerade jetzt mein Flow sieht wie folgt aus:

  1. Führen Sie den Build
  2. Uhr für „undefined reference“ Fehler
  3. Herauszufinden, welche Paket fehlt durch den Fehler googeln oder auf der Suche auf den Namen verwiesen wird (zB nettle_sha1_digest = Brennnessel-Paket)
  4. Installieren Sie das Paket
  5. Repeat

ich denke, ich frage mich, ob es eine magische bul ist lass das alle Abhängigkeiten für mich installieren? :)

Antwort

1

Aus dem Aussehen davon verknüpfen Sie Ihre abhängigen Bibliotheken in der falschen Reihenfolge (siehe Why does the order in which libraries are linked sometimes cause errors in GCC? für mehr Kontext).

Mit statisch verknüpften Bibliotheken versucht der Linker, Symbole in der Reihenfolge aufzulösen, in der die Bibliotheken angegeben wurden. Wenn ein veraltetes Symbol als undefiniert auftaucht, sucht der Linker, ob es in den nachfolgenden Bibliotheken definiert ist. Da in Ihrem Buildaufruf -lnettlevor-lgnutls angegeben ist, kann die gnutls-Bibliothek die Symbole, die sie benötigt, nicht aus Brennnessel auflösen.

Dies bedeutet, dass (mindestens) Sie Ihre Referenz auf -lnettle nach -lgnutls verschieben müssen. Nicht sicher, dass dies alle Ihre Probleme lösen wird, da ich nicht mit allen aufgelisteten Verknüpfungsabhängigkeiten vertraut bin, aber es sollte zumindest Ihre aktuellen Fehler beheben, die go build ausführen.

+0

Der Hauptgrund, dass Sie all diese Linker-Flags hinzufügen müssen, ist die Tatsache, dass Sie versuchen, alles statisch zu kompilieren. Angenommen, Sie verwenden die dynamische Verknüpfung 'go build', ohne dass zusätzliche Linker-Flags funktionieren sollten, da Shared Libraries Verweise auf ihre eigenen Abhängigkeiten speichern. Aber, da du Musl verwendest, gehe ich davon aus, dass du versuchst, das für eine leichtere Verteilung komplett statisch zu bekommen? – photoionized

Verwandte Themen