mcabber -> libcrypto.so.0.9.8: could not read symbols: Invalid operation

level20peon

Mitglied
Mitglied seit
11 Jul 2007
Beiträge
270
Punkte für Reaktionen
0
Punkte
16
Das Bauen von mcabber für die 7490 vom aktuellen trunk führt zu oben genanntem Fehler, das komplette Log:

WARNING: The program composite was not found in path.
WARNING: The header file readline/readline.h was not found in /usr/(local/)include.
cmd() { PATH="/home/bofh/7490/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/bin:/home/bofh/7490/toolchain/build/mips_gcc-4.8.5/mips-unknown-linux-gnu/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games" LD_RUN_PATH="/usr/lib/freetz" make -j2 "$@" || { 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-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10 \
LDFLAGS=""
make[1]: Entering directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10'
make all-recursive
make[2]: Entering directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10'
Making all in connwrap
make[3]: Entering directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10/connwrap'
make[4]: Entering directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10/connwrap'
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10/connwrap'
make[3]: Leaving directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10/connwrap'
Making all in libjabber
make[3]: Entering directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10/libjabber'
make[4]: Entering directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10/libjabber'
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10/libjabber'
make[3]: Leaving directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10/libjabber'
Making all in src
make[3]: Entering directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10/src'
../hgcset.sh
make all-am
make[4]: Entering directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10/src'
../hgcset.sh
/home/bofh/7490/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/bin/mips-linux-uclibc-gcc -DHAVE_CONFIG_H -I. -I.. -I/home/bofh/7490/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/usr/include/glib-2.0 -I/home/bofh/7490/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/usr/lib/glib-2.0/include -I/home/bofh/7490/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/usr/include -march=24kc -mtune=24kc -msoft-float -Os -pipe -Wa,--trap -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -I/usr -D_GNU_SOURCE -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.c
/home/bofh/7490/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/bin/mips-linux-uclibc-gcc -DHAVE_CONFIG_H -I. -I.. -I/home/bofh/7490/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/usr/include/glib-2.0 -I/home/bofh/7490/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/usr/lib/glib-2.0/include -I/home/bofh/7490/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/usr/include -march=24kc -mtune=24kc -msoft-float -Os -pipe -Wa,--trap -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -I/usr -D_GNU_SOURCE -MT jab_iq.o -MD -MP -MF .deps/jab_iq.Tpo -c -o jab_iq.o jab_iq.c
mv -f .deps/main.Tpo .deps/main.Po
mv -f .deps/jab_iq.Tpo .deps/jab_iq.Po
/home/bofh/7490/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/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 -Wall -I/usr -D_GNU_SOURCE -o mcabber main.o roster.o events.o jabglue.o jab_iq.o commands.o compl.o hbuf.o screen.o settings.o hooks.o utf8.o histolog.o utils.o pgp.o fifo.o help.o -pthread -L/home/bofh/7490/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/usr/lib -lglib-2.0 -lpcre ../libjabber/liblibjabber.a ../connwrap/libconnwrap.a -lssl -lpanel -lncurses
/home/bofh/7490/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/bin/../lib/gcc/mips-linux-uclibc/4.8.5/../../../../mips-linux-uclibc/bin/ld: ../connwrap/libconnwrap.a(connwrap.o): undefined reference to symbol 'ASN1_STRING_free'
/home/bofh/7490/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/bin/../lib/gcc/mips-linux-uclibc/4.8.5/../../../../mips-linux-uclibc/bin/ld: note: 'ASN1_STRING_free' is defined in DSO /home/bofh/7490/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/bin/../usr//lib/libcrypto.so.0.9.8 so try adding it to the linker command line
/home/bofh/7490/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/bin/../usr//lib/libcrypto.so.0.9.8: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
make[4]: *** [mcabber] Error 1
make[4]: Leaving directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10/src'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10'

ERROR: Build failed.
make: *** [source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10/src/mcabber] Error 1

Wer kann mir helfen?
 
Wenn mcabber nicht statisch mit der alten OpenSSL-Version 0.9.8 gelinkt werden soll (das muß man raten, weil die Infos alle fehlen), dann ist das die falsche SSL-Version, denn die 7490 verwendet - wie alle anderen Modelle - ab 06.20 die OpenSSL-Version 1.0.1 ... da stimmt also irgendetwas nicht.

Vielleicht ist ja auch nur die Build-Umgebung nicht "sauber" ... Du hast nicht zufällig irgendwelche Reste eines früheren Builds (vor 06.20) dort noch drin?

Der alte Kommentar bei der Auswahl der OpenSSL-Version stimmt ja inzwischen auch nicht mehr ... die AVM-Firmware verwendet inzwischen eben ihrerseits eine 1.0.1-Version, damit wäre die Verwendung einer 0.9.8 bei einer 7490 mit einiger Wahrscheinlichkeit eher ein Mißverständnis, solange man das nicht sehr bewußt gemacht hat - in diesem Falle sollte man dann aber auch nicht fragen müssen.
 
Die Option "Statically link libraries" bei mcabber ist deaktiviert, ein Aktivieren führt jedoch auch nicht zum Bauen des images. Die build Umgebung ist so sauber wie sie nur sein kann. Der oben eingefügte output wurde generiert nachdem ich den trunk ausgecheckt, via menuconfig mcabber + "with SSL-Support" ausgewählt habe, und danach dann "make" ausgeführt habe.

Welche zusätzlichen Infos würden hier weiter helfen?
 
Teile dieser Informationen hast Du ja schon nachgeliefert, die config-Datei fehlt halt noch.

Ich habe bei CS 13445 jedenfalls keine Probleme, "mcabber" auch mit dynamischen Libraries zu erstellen - ebenfalls für die 7490 und mit der höchsten derzeit unterstützten Firmware 06.30.

Warum bei Dir da eine Referenz zu einer überhaupt nicht benötigten OpenSSL-Version auftaucht, weiß ich auch nicht ... aber Du könntest ja problemlos nachsehen, was bei Dir bzgl. der OpenSSL-Version eingestellt ist.

Ich weiß nicht, ob die Auswahl der OpenSSL-Version 1.0.1 ab einer verwendeten AVM-Firmware-Version 06.20 automatisch erfolgt in Freetz ... wenn Du da nichts geändert hast und es steht tatsächlich auf 0.9.8, kannst Du ja problemlos auf 1.0.1 ändern.
 
Dies ist die benutze ".config": Anhang anzeigen config.txt

Ich habe jetzt mal OpenSSL Version 1.0.1p ausgewählt, das führt zum selben Fehler wie zuvor, nur eben mit geänderter Versionsnummer im log:

WARNING: The program composite was not found in path.
WARNING: The header file readline/readline.h was not found in /usr/(local/)include.
cmd() { PATH="/home/bofh/7490/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/bin:/home/bofh/7490/toolchain/build/mips_gcc-4.8.5/mips-unknown-linux-gnu/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games" LD_RUN_PATH="/usr/lib/freetz" make -j2 "$@" || { 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-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10 \
LDFLAGS=""
make[1]: Entering directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10'
make all-recursive
make[2]: Entering directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10'
Making all in connwrap
make[3]: Entering directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10/connwrap'
make[4]: Entering directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10/connwrap'
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10/connwrap'
make[3]: Leaving directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10/connwrap'
Making all in libjabber
make[3]: Entering directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10/libjabber'
make[4]: Entering directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10/libjabber'
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10/libjabber'
make[3]: Leaving directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10/libjabber'
Making all in src
make[3]: Entering directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10/src'
../hgcset.sh
make all-am
make[4]: Entering directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10/src'
../hgcset.sh
/home/bofh/7490/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/bin/mips-linux-uclibc-gcc -DHAVE_CONFIG_H -I. -I.. -I/home/bofh/7490/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/usr/include/glib-2.0 -I/home/bofh/7490/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/usr/lib/glib-2.0/include -I/home/bofh/7490/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/usr/include -march=24kc -mtune=24kc -msoft-float -Os -pipe -Wa,--trap -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -I/usr -D_GNU_SOURCE -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.c
/home/bofh/7490/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/bin/mips-linux-uclibc-gcc -DHAVE_CONFIG_H -I. -I.. -I/home/bofh/7490/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/usr/include/glib-2.0 -I/home/bofh/7490/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/usr/lib/glib-2.0/include -I/home/bofh/7490/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/usr/include -march=24kc -mtune=24kc -msoft-float -Os -pipe -Wa,--trap -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -I/usr -D_GNU_SOURCE -MT jab_iq.o -MD -MP -MF .deps/jab_iq.Tpo -c -o jab_iq.o jab_iq.c
mv -f .deps/main.Tpo .deps/main.Po
mv -f .deps/jab_iq.Tpo .deps/jab_iq.Po
/home/bofh/7490/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/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 -Wall -I/usr -D_GNU_SOURCE -o mcabber main.o roster.o events.o jabglue.o jab_iq.o commands.o compl.o hbuf.o screen.o settings.o hooks.o utf8.o histolog.o utils.o pgp.o fifo.o help.o -pthread -L/home/bofh/7490/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/usr/lib -lglib-2.0 -lpcre ../libjabber/liblibjabber.a ../connwrap/libconnwrap.a -lssl -lpanel -lncurses
/home/bofh/7490/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/bin/../lib/gcc/mips-linux-uclibc/4.8.5/../../../../mips-linux-uclibc/bin/ld: ../connwrap/libconnwrap.a(connwrap.o): undefined reference to symbol 'ASN1_STRING_free'
/home/bofh/7490/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/bin/../lib/gcc/mips-linux-uclibc/4.8.5/../../../../mips-linux-uclibc/bin/ld: note: 'ASN1_STRING_free' is defined in DSO /home/bofh/7490/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/bin/../usr//lib/libcrypto.so.1.0.0 so try adding it to the linker command line
/home/bofh/7490/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/bin/../usr//lib/libcrypto.so.1.0.0: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
make[4]: *** [mcabber] Error 1
make[4]: Leaving directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10/src'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/bofh/7490/source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10'

ERROR: Build failed.
make: *** [source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mcabber-0.9.10/src/mcabber] Error 1
 
Zuletzt bearbeitet:
Im Basis-Verzeichnis des Trunks:

make openssl-distclean
make mcabber-distclean
./fmake

Das Ergebnis (Datei fmake.log) hier anhängen (das meint als Attachment und nicht "im Volltext").

Vielleicht vorher einfach noch "libreadline-dev" als Paket installieren (unter der Annahme, daß das ein Ubuntu bei Dir ist), dann ist auch die Warnung bzgl. "readline" weg ... sollte mcabber das auf seiner Kommandozeile sogar verwenden (ncurses braucht er ja auch), kommst Du ohnehin nicht daran vorbei.

Wenn Du dann auch noch "GraphicsMagic" installierst, ist auch die allererste Warnung zum fehlenden "composite" noch weg ... allerdings stört dessen Fehlen nur dann, wenn Du die AVM-Pictures irgendwie verändern lassen willst.

EDIT: Abgesehen davon ist die fehlende ASN1_STRING_free-Funktion tatsächlich in der libcrypto zu finden, die aber beim Linken bei mir auch eingebunden wird:
Code:
/home/PeterPawn/trunk/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/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 -Wall -I/usr -D_GNU_SOURCE   -o mcabber main.o roster.o events.o jabglue.o jab_iq.o commands.o compl.o hbuf.o screen.o settings.o hooks.o utf8.o histolog.o utils.o pgp.o fifo.o help.o  -pthread -L/home/PeterPawn/trunk/toolchain/build/mips_gcc-4.8.5_uClibc-0.9.33.2-nptl/mips-linux-uclibc/usr/lib -lglib-2.0 -lpcre      ../libjabber/liblibjabber.a ../connwrap/libconnwrap.a -lssl [COLOR="#FF0000"]-lcrypto[/COLOR] -ldl -lpanel  -lncurses
Wenn die bei Dir nicht angegeben ist, läuft wohl irgendetwas mit dem "configure" für das mcabber-Paket falsch ... aber das steht dann auch in der fmake.log (ich setze "Verbosity 2" voraus, das habe ich oben noch vergessen zu schreiben).
 
Zuletzt bearbeitet:
Anbei hänge ich fmake.log an.

Die beiden Warnungen sind scheinbar nicht die Ursache des Problems, da der Fehler auch nach der Installation der beiden entsprechenden Pakete weiterhin auftritt.
 

Anhänge

  • fmake.zip
    23.1 KB · Aufrufe: 2
EDIT: #6 hatte ich noch etwas hinzugefügt, Dein Protokoll bestätigt diese Vermutung im Prinzip.

An der Stelle, wo die Entscheidung für das Einbinden der libcrypto beim Linken gefällt wird:
Code:
[...]
checking for OpenSSL... found in /usr
checking for main in -lcrypto... (cached) [COLOR="#FF0000"]yes[/COLOR]
checking for main in -lssl... (cached) yes
configure: creating ./config.status
[...]
steht bei Dir ein "no" ... das kann nur ein eigentlich falsches Ergebnis eines früheren Tests sein (cached) oder es liegt doch an der anderen verwendeten OpenSSL-Version (weiß ich im Moment nicht sicher, kann/will ich auch nicht testen). Warum Du bei einer aktuellen Firmware-Version weiterhin die 0.9.8 ZUSÄTZLICH! verwenden willst (denn die AVM-Komponenten brauchen die 1.0.1 ja weiterhin), verstehe ich ohnehin nicht und auch ob eine "friedliche Koexistenz" der beiden Versionen zur Laufzeit ohne weiteres möglich ist, würde ich nicht beschwören - "/lib/libcrypto.so" als "pauschaler Link" kann ja nur auf die libcrypto.so.1.0.0 oder auf die libcrypto.so.0.9.8 verweisen und nicht auf beide gleichzeitig.

Jedenfalls sollte ein "make distclean", gefolgt von einem "make menuconfig", bei dem Du sowohl OpenSSL auf 1.0.1 umstellst als auch Dein mcabber-Paket auswählst, das Paket eigentlich erstellen. Wenn das funktioniert, kann es ja nur noch an Deinem Build-System oder Deiner Konfiguration liegen (altes Trunk-Verzeichnis einfach aufheben, z.B. in gepackter Form). Ich werde das nicht meinerseits mit der alten OpenSSL-Version nachstellen und für ein komplettes "make distclean" bei mir selbst oder auch für einen frisch ausgecheckten Trunk fehlt mir die Zeit (das Kompilieren dauert mir zu lange).

Wenn Du einen weniger aussagekräftigen Test machen willst (der aber auch wesentlich weniger Zeit braucht), löschst Du zusätzlich noch die Datei "config.cache" im Verzeichnis source/target-mips_gcc-4.8.5_uClibc-0.9.33.2-nptl und führst dann die Kommandos aus #6 erneut aus - diesmal sollte dann "ac_cv_lib_crypto_main=${ac_cv_lib_crypto_main=yes}" in der "config.cache" landen. Ist das nicht der Fall, kommt schon irgendein "configure" davor durcheinander.

Solltest Du weiterhin Probleme haben, würde ich Dir trotzdem das komplette "make distclean" empfehlen (ob Du die Konfiguration aufhebst und wiederverwendest, mußt Du schon selbst entscheiden) ... irgendwo kommt das "configure" bei Dir halt durcheinander - die Ursache ist im Nachhinein schwer zu ermitteln, daher lautet die Patentlösung an dieser Stelle: Zurück auf "LOS" und diesmal eben alles mitprotokollieren lassen (dafür gibt es das "fmake" ja). Die OpenSSL-Version sollte damit tatsächlich nichts zu tun haben (zur Compile-Time zumindest nicht), meine Anmerkung oben bleibt aber weiterhin gültig.
 
Zuletzt bearbeitet:
"make distclean" nach Auswählen der 1.0.1 OpenSSL Version führte zum Bauen des Images. Komisch eigentlich, weil ich an der OpenSSL Version bisher nie irgendwas geändert habe (ich nutze freetz nun seit 8 Jahren). Naja, öfter mal was neues, denke ich.

Vielen Dank für die Hilfe :D
 
... oder auch doch nicht. Ich habe gerade wieder komplett von vorne angefangen (svn co...) und direkt die 1er OpenSSL Version ausgewählt. Nun taucht trotzdem wieder der eingangs beschriebene Fehler auf.
Und das make distclean führte zwar zum Bauen des Images, jedoch fehlte die Hälfte der ausgewählten Pakete.
 
Nochmal ganz klar: Du hast OpenSSL 1.0.1 für das Image ausgewählt und trotzdem wird versucht, das "mcabber"-Paket mit der OpenSSL-Version 0.9.8 zu erstellen?

Das klingt recht unwahrscheinlich, es wäre hilfreich, wenn Du das mit einem passenden "fmake.log" untermauern könntest ... nicht daß ich Dir nicht glauben will, aber wenn da nicht sehr merkwürdige Umstände zusammenkommen, läge ein Konfigurationsfehler Deinerseits irgendwie näher.

Also bitte noch einmal von vorne (gerne auch mit "svn checkout" beginnend, dann aber auch in ein neues Verzeichnis) und anstatt des "make" (nach dem make menuconfig) dann eben fmake verwenden. Die Ausgabe kann man auch parallel im Terminal sehen und in der Datei speichern, die notwendigen Optionen verrät "fmake" selbst.

Wenn das tatsächlich so sein sollte, hätte eben ein anderes Paket (das habe ich bereits einmal geschrieben) in der "config.cache" falsche Feststellungen hinterlassen und um welches Paket es sich dabei handelt, kann man eben nur mit einem kompletten Log feststellen. Dann würde das "autoconf" für das mcabber-Paket gar nicht mehr selbst nach der "libcrypto" suchen und die Ergebnisse eines zuvor ausgeführten "autoconf" verwenden ... eine recht ungewöhnliche Konstellation. Auch habe ich bereits den Hinweis gegeben, welche Einstellung in der config.cache zu prüfen wäre ... im letzten Beitrag fehlt praktisch alles, von der .config über das Protokoll bis zum Nachsehen Deinerseits in der config.cache. Außer viel Schreibarbeit bringt da ein erneuter Versuch der Hilfe eigentlich gar nichts ...
 
Ich habe OpenSSL 1.0.1 ausgewählt und mcabber versucht auch diese Version zu verwenden. Nach den ursprünglich beschriebenen Problemen dachte ich, dass bei einem komplett neuen build (also "svn co..." in ein neues Verzeichnis) das Auswählen von Version 1.0.1 ganz zu Anfang vielleicht zur Lösung des Problems führt. Tut es aber nicht.

Das (komplette) fmake.log habe ich angehängt.

Das Nachsehen in der config.cache entfällt denke ich mal, da mein Problem nicht das Auswählen der falschen OpenSSL Version ist, sondern dass ein "libcrypto.so.*.*.*: could not read symbols: Invalid operation" ausgegeben wird... oder liege ich falsch? Ob ich nun 1.0.1 oder 0.9.8 ganz zu Anfang auswähle (nochmal, frisches Verzeichnis mit "svn co...") führt am Ende in beiden Fällen zum selben Fehler - nur eben mit entsprechend unterschiedlichen Versionsnummern hinter dem "libcrypto.so".
 

Anhänge

  • fmake.zip
    273.9 KB · Aufrufe: 5
  • .config.zip
    12.2 KB · Aufrufe: 2
oder liege ich falsch?
Ja.

Ob ich nun 1.0.1 oder 0.9.8 ganz zu Anfang auswähle (nochmal, frisches Verzeichnis mit "svn co...") führt am Ende in beiden Fällen zum selben Fehler - nur eben mit entsprechend unterschiedlichen Versionsnummern hinter dem "libcrypto.so".
Ganz einfach deshalb, weil bei Dir wegen der Feststellung im Log-File:
Code:
49068 - checking for main in -lcrypto... [COLOR="#FF0000"](cached)[/COLOR] [B][COLOR="#FF0000"]no[/COLOR][/B]
49069 - checking for main in -lssl... yes
die libcrypto.so beim Linken gar nicht hinzugezogen wird (anders als die libssl.so ... schau Dir einfach das Kommando zum Linken im Log und die "config.in" für mcabber an). Damit schlägt eine automatische Auflösung des fehlenden Symbols "ASN1_STRING_free" zu und dabei wird im Toolchain-Verzeichnis (nicht im "target..."-Verzeichnis, wo die richtige läge) eine libcrypto.so gefunden, die dann beim Linken verwendet wird und logischerweise (ich gehe davon aus, daß Du auf einem x86-System arbeitest) hat diese ein falsches Format.

Da das Ergebnis der Abfrage für die libcrypto.so bei Dir schon wieder "(cached)" ist (s.o.), muß das bei einem "frischen Build" ja irgendjemand dort so abgelegt haben ... bei der libssl.so ist es offenbar nicht der Fall (zweite Zeile oben). Entweder Du versuchst nun mal tatsächlich, den "Schuldigen" zu finden oder ich weiß auch nicht mehr, wie ich Dir weiterhelfen soll. Die "libcrypto.so.1.0.0" im Target-Verzeichnis wird jedenfalls in Zeile 47527 der Protokoll-Datei erstellt - obwohl schon vorher in Zeile 47169 (bei den Beispielen/Tools) versucht wird, sie zu verwenden. Das sieht nach falschen Abhängigkeiten/einer falschen Reihenfolge beim Build aus - macht sich halt bei den OpenSSL-Beispielen nicht wirklich bemerkbar. Ob am Ende eine korrekte libcrypto.so.1.0.0 für das Zielsystem im "target..."-Verzeichnis vorhanden ist, kannst auch wieder nur Du selbst prüfen.

Eventuell als Workaround (wenn die Abhängigkeiten stimmen, was ich nicht weiß) vor dem eigentlichen Build mit "mcabber-precompiled" als Ziel dafür sorgen, daß da niemand vorher den Cache mit einer falschen Angabe (Name siehe weiter oben) "vergiftet", wenn es nicht ohnehin eines der Pakete selbst ist (was diese Angabe setzt), die für das Erstellen von mcabber gebraucht werden.

Vielleicht prüft da irgendein Paket (bei dem die Abhängigkeit vom OpenSSL nicht berücksichtigt wird/wurde) schon vor dem Bauen des OpenSSL-Paketes, ob die libcrypto.so.1.0.0 existiert ... das kriegst Du aber selbst heraus, mir fehlt zugegebenermaßen der Antrieb, die 47.000 Zeilen davor nach einer entsprechenden Fundstelle zu durchsuchen - zumal die sich mit einem "grep" für "crypto" oder "lcrypto" offenbar nicht einfach lokalisieren läßt. Auf die Idee, ein Image sowohl mit OpenSSL als auch GnuTLS (jeweils mit dynamischen Libs) bauen zu lassen (die haben beide eine libcrypto, da könnte am Ende auch die falsche gefunden werden), wirst Du ja nicht gekommen sein ... falls das mit Freetz überhaupt geht.

Man muß also hingehen und eine Liste der Pakete in ihrer Build-Reihenfolge erstellen, damit man dort im "source"-Verzeichnis suchen kann, wer diese gespeicherte Einstellung verbrochen hat. Bei der Fehlersuche kann Dich eine Einstellung im Freetz ("Backup config.cache") unterstützen ... bei mir selbst tritt das Problem - wie bereits geschrieben - nicht auf, es kann/sollte/muß also irgendwie mit Deiner Paketauswahl zu tun haben (ich würde als erstes mal "GnuTLS" weglassen beim nächsten "clean build").

Zur Deiner .config kann ich nur noch sagen, daß ich Deinen Mut bewundere, so konsequent bei einer aktuellen Firmware-Version jede Menge "remove"-Patches zu verwenden (Platzprobleme können es eigentlich nicht sein) ... die Abhängigkeiten haben sich da deutlich verschoben und wenn Du so viel entfernen läßt, kann es Dir durchaus passieren, daß auch andere Teile nicht mehr richtig funktionieren ... aber das merkt man ohnehin erst dann, wenn man mit einem funktionierenden Image arbeiten will und bis dahin hast Du vermutlich noch etwas Weg vor Dir.
 
Wenn Du den relevanten Teil (daß die Bibliotheken zusätzlich verwendet werden) noch zitiert hättest, gebe ich Dir unumwunden recht ... hier macht es sich dann tatsächlich bemerkbar, daß ich selbst gar kein Freetz auf der Box einsetze und daher bei mir alle zusätzlichen Pakete mit der originalen SSL-Bibliothek von AVM laufen - ich habe von der Anwendung eines Freetz-Images tatsächlich nur wenig Ahnung.

Warum das mit den doppelten Libs bei Freetz nach wie vor der Fall ist - die Zeiten der "AVM-Spezialversion" sind lange vorbei -, weiß ich auch nicht ... diese Trennung war früher einmal erforderlich, weil die Bibliotheken in der AVM-Firmware Modifikationen enthielten bzw. recht "unvollständig" waren oder eben genau deshalb, weil man auf diese Weise die neuere OpenSSL-Version auch schon einsetzen konnte, während AVM selbst noch die ältere 0.9.8irgendwas im Einsatz hatte.

Wenn das Freetz tatsächlich heute noch so zusammenpackt (diesen Schritt gibt es bei mir praktisch nicht), gibt es da (zumindest bei der 7390 und bei Platzproblemen) erhebliches Einsparungspotential, wenn man einfach die AVM-Version weiterhin verwendet ... es funktioniert bei mir auf der 7390 jedenfalls problemlos und die AVM-Version ist (etwas abhängig davon, mit welchen Settings man die beim Freetz baut) umfangreicher. Dazu muß man ja nur die (identische Version) aus dem Verzeichnis /usr/lib/freetz löschen, die in /lib wird dann schon gefunden.

Wenn irgendein Programm tatsächlich mit der AVM-Version nicht funktionieren sollte, wird vermutlich eine benötigte Funktion nicht enthalten sein, ein Vergleich des Funktionsumfangs ginge z.B. so:
Code:
nm -D lib/libcrypto.so | sed -n -e "s/^.* .* \(.*\)\$/\1/p" | sort | tee /tmp/avm.syms
nm -D usr/lib/freetz/libcrypto.so | sed -n -e "s/^.* .* \(.*\)\$/\1/p" | sort | tee /tmp/freetz.syms
diff /tmp/freetz.syms /tmp/avm.syms
Fazit: Beschränkt auf den "zusätzlich"-Passus aus #8 gebe ich Dir also recht ... der Rest meiner Ausführungen gilt weiterhin - wenn Du den widerlegen möchtest, wäre ein etwas ausführlicherer Text nett.
 
Der workaround mit "mcabber-precompiled" löste mein Problem und führt zum build - auch wenn der in deinen Augen äußerst fragwürdige Aktionen beinhaltet. Ich möchte mich nochmals für die Geduld und Hilfe bedanken :)
 
@level20peon:
1. Na dann ...

2. Von "fragwürdig" habe ich nichts (oder wenig) geschrieben ... wenn man tatsächlich weiß, was man da macht, kann das klappen; ich baue selbst auch alle SSL-Stacks - schon zum Vergleichen und Testen.

3. Gern geschehen ... viel Erfolg.

Solltest Du am Ende Probleme bei der Verwendung des Images haben, kannst Du ja noch einmal über die Frage nachdenken, weshalb Du sowohl GnuTLS als auch OpenSSL verwendest ... es mag ja gute Gründe geben (auch wenn ich wenige Pakete kenne, die ausschließlich GnuTLS unterstützen - selbst das "GNU Wget" unterstützt OpenSSL - magst Du ja Deine Gründe haben) , ich habe bisher dazu halt nichts von Dir gelesen.

Die ganzen "remove"-Patches können auch tatsächlich funktionieren ... es kommt halt immer darauf an, welche Teile der "stock firmware" am Ende auch weiterhin verwendet werden und daß da nichts dabei ist, was plötzlich doch (bei der 06.30) noch gebraucht wird. Wobei mir da zugegebenermaßen auch der Überblick fehlt, welcher Patch da was genau löscht (ich selbst brauche keinen dieser Patches) ... wenn die (schon älteren) Patches tatsächlich noch 1:1 passen sollten, würde es mich aber eher wundern. Da das ohnehin in weiten Teilen für die 06.36 bzw. das folgende Release zu überarbeiten ist, spielt das aber auch nur eine untergeordnete Rolle.

Bei den dynamischen Bibliotheken besteht die "Verwechselungsgefahr" bei der libcrypto auch nicht mehr, die "libcrypto.a" als statische Library gibt es beim GnuTLS nur zur Compile-Time (Zeile 42858 des Protokolls in #12 und da vermute ich auch irgendwo das Problem, was zum fehlenden Linken mit der libcrypto.so bei mcabber führt) und eine "libcrypto.so" gibt es beim GnuTLS meines Wissens nicht. Es kann also höchstens noch sein, daß ein Programm versehentlich gegen die statische libcrypto.a aus dem GnuTLS-Paket gelinkt wurde (was der Linker aber eigentlich merken sollte, insofern ist vermutlich ohnehin alles Wölkchen). Diese zusätzliche "libcrypto.a" vor dem Erstellen der libcrypto.so durch das OpenSSL-Paket könnte problemlos dazu führen, daß irgendein Paket seinerseits feststellt, daß die libcrypto.so nicht als dynamische Bibliothek vorliegt (folglich auch nicht mit "-lcrypto" beim Linken anzugeben wäre) und das Ergebnis dann im Cache landet, von wo es mcabber ausliest anstatt es erneut zu testen.

Das Fiese an solchen Problemen zur Laufzeit ist es halt, daß diese wesentlich schlechter zu finden sind als irgendwelche Compiler-Warnungen und -Errors ... in der Regel gibt es eben einen "blue screen" (im übertragenen Sinne) und einen Neustart. Wenn Du von alledem verschont bleibst, ist ja alles in Butter.
 
Zuletzt bearbeitet:

Neueste Beiträge

Statistik des Forums

Themen
244,695
Beiträge
2,216,691
Mitglieder
371,315
Neuestes Mitglied
jack-mack
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.