audacity ABI Fehler

klimaschreck

Well-Known Member
Hallo zusammen,

wenn ich audacity auf FBsd 10.3 amd starte, erhalte ich folgende Fehlermeldung:

Code:
Fatal Error: Mismatch between the program and library build versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1002,wx containers,compatible with 2.6,compatible with 2.8),
and your program used 3.0 (wchar_t,compiler with C++ ABI 1009,wx containers,compatible with 2.6,compatible with 2.8).
Abort trap

Ich habe folgende libraries installiert:

Code:
wx28-gtk2-2.8.12_7
wx28-gtk2-common-2.8.12_7
wx30-gtk2-3.0.2_6

Ich habe alle Anwendungen über synth erstellen lassen. Damit hatte ich gedacht, würde es keine Probleme bei den Abhängigkeiten geben. Habt ihr eine Idee, wie ich die ABI der library auf 1009 bringen kann, nach Möglichkeit mit synth?
 
Ich habe synth noch nie genutzt und auch erst in dem letzten Thread wo wir mit vermutlichen Inkonsistenzen auf deinem System zu tun hatten, davon erfahren. Deshalb will ich überhaupt nichts zu synth sagen.
Aber, mit Blick auf den letzten Beitrag: bist du eigentlich sicher, dass du inzwischen dein System soweit sauber hast? An einer einzigen Stelle zu reparieren, wenn es nicht vollständig klar ist, bringt meiner Ansicht nach nicht sehr viel.
Ich empfehle deshalb weiterhin die bsdadminscripts2-0.2.0 (in der Version als aktuelles Paket zu bekommen) und daraus die Funktion pkg_libchk(1), möchte aber auch wieder ausdrücklich darauf hinweisen, dass ich diese scripts selbst regelmäßig nur benutzt habe, so lange ich Ports benutzte und heute nur gelegentlich mal damit etwas aufräume. Wer Pakete benutzt, hat sein System einfach in Ordnung. Insbesondere die neuere Version 2 der bsdadminscripts habe ich mir noch nicht angesehen oder sie benutzt. Sie ist aber (wie ich in einem anderen Beitrag gelesen habe) auf pkgng abgestimmt und entsprechend erneuert.
Mit pkg_libchk konnte man von installierten Programmen die benötigten Libs checken lassen und als Ausgabe eine Liste mit Fehlern erhalten. Diese konnte so aussehen, dass man sie automatisch einer Neubau-Anweisung übergeben konnte. So etwas sollte auch mit synth funktionieren.
 
Frisch Gehacktes:
Code:
--- x11-toolkits/wxgtk30/Makefile.orig  2017-06-11 23:44:50.401872000 +0200
+++ x11-toolkits/wxgtk30/Makefile       2017-06-11 23:47:28.360861000 +0200
@@ -15,7 +15,8 @@
                libtiff.so:graphics/tiff \
                libexpat.so:textproc/expat2
-USES=          compiler:c++11-lib execinfo gmake iconv jpeg pkgconfig tar:bzip2
+USES=           compiler:gcc-c++11-lib execinfo gmake iconv jpeg pkgconfig tar:bzip2
+USE_GCC=        4.9+
USE_XORG=      x11 sm xxf86vm xinerama
USE_GL=                glu
USE_GNOME=     gtk20

Konnte den audacity ABI Fehler hier auf 10.3 STABLE nachvollziehen. Fand dann bei denen mit den roten und blauen Hüten den entsprechenden Hinweis [1], dass die Prüfungen auf die wxGTK ABI wohl ein wenig zu streng wären. Aber bin dann den einfachen FreeBSD Weg gegangen und habe mal in das Makefile vom audacity hineingeguckt, wie genau dort der Compiler ausgewählt wird und habe das dann in das x11-toolkits/wxgtk30/Makefile übernommen, kurz mal neugebaut und schon läuft audacity wieder, jedenfalls hier bei mir hat das geholfen. :)

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1200611
 
Update:

Was ich nicht bedacht habe, wenn die wxgtk30 Bibliothek auf die C++ ABI 1009 gehoben wird, dann müssen auch die restlichen Anwendungen, welche die wxgtk30 Bibliothek verwenden, auf die C++ ABI 1009 gehoben werden. Bei audacity ist das ja bereits der Fall und war das Problem. Aber nun, mit der wxgtk30 Bibliothek auf der C++ ABI 1009 gibt es dann zwar das eine Problem mit audacity weniger, aber beispielsweise hugin meckert dann und läuft nicht mehr, weil hugin noch die C++ ABI 1002 haben möchte. :ugly:
50 Ports nutzen die wxgtk30 Bibliothek:
https://www.freshports.org/x11-toolkits/wxgtk30/

Habt ihr auch gerade den Elefant im Porzellanladen gesehen? :apaul:
 
Für POLA dürfte das hier besser sein, damit bleibt audacity auf der C++ ABI 1002, an der wxgtk30 Bibliothek muss nichts geändert werden und es hat dann auch keine schwer wiegenden Folgen für die 50 Ports, welche die wxgtk30 Bibliothek verwenden:
Code:
--- audio/audacity/Makefile.orig        2017-06-13 07:14:24.056835000 +0200
+++ audio/audacity/Makefile     2017-06-13 06:44:07.693087000 +0200
@@ -1,5 +1,5 @@
# Created by: Marc van Woerkom <3d@FreeBSD.org>
-# $FreeBSD$
+# $FreeBSD: head/audio/audacity/Makefile 442783 2017-06-06 16:18:16Z mat $
PORTNAME=      audacity
PORTVERSION=   2.1.3
@@ -27,6 +27,7 @@
NLS_CONFIGURE_WITH=    libintl-prefix="${LOCALBASE}"
OPTIONS_SUB=   yes
USE_GCC=       4.9+
+CXXFLAGS+=      -fabi-version=2
USE_WX=                3.0+
WX_COMPS=      wx
INSTALLS_ICONS=        yes

hugin baut zwar quasi mühelos mit compiler:gcc-c++11 und USE_GCC= 4.9+, aber schon beim wxlauncher ist es nicht mehr so einfach. Unnötig abweichen von POLA können FreeBSDler doch nicht wirklich wollen. :)
 
@pit234a
Ich habe alle Pakete deinstalliert und neu gebaut mit synth. pkg_libcheck ergabe folgendes Ergebnis:

Code:
handbrake-1.0.7: /usr/local/bin/HandBrake misses libstdc++.so.6
handbrake-1.0.7: /usr/local/bin/HandBrakeCLI misses libstdc++.so.6
handbrake-1.0.7: /usr/local/bin/ghb misses libstdc++.so.6
ELF binary type "6" not known.
ELF binary type "6" not known.
ELF binary type "6" not known.
ELF binary type "6" not known.
ELF binary type "6" not known.
ELF binary type "0" not known.
ELF binary type "0" not known.
ELF binary type "0" not known.
ELF binary type "0" not known.
ELF binary type "0" not known.
ELF binary type "6" not known.
ELF binary type "6" not known.
ELF binary type "0" not known.
ELF binary type "0" not known.
ELF binary type "0" not known.
ELF binary type "0" not known.
ELF binary type "6" not known.
ELF binary type "6" not known.
nspluginwrapper-1.4.4_7: /usr/local/lib/nspluginwrapper/i386/linux/libnoxshm.so misses libc.so.6
opera-12.16_6: /usr/local/lib/opera/gstreamer/plugins/libgstoperamatroska.so misses libxml2.so.5
opera-12.16_6: /usr/local/lib/opera/gstreamer/plugins/libgstoperavp8.so misses libxml2.so.5
opera-12.16_6: /usr/local/lib/opera/liboperakde4.so misses libkdeui.so.7
opera-12.16_6: /usr/local/lib/opera/liboperakde4.so misses libkio.so.7
opera-12.16_6: /usr/local/lib/opera/liboperakde4.so misses libkdecore.so.7
swt-devel-3.7.1_3,1: /usr/local/lib/libswt-awt-gtk-3738.so misses libjawt.so
 
@Fusselbär vielen Danke für dein Hinweis und dein Patch, Ich habe mir den Patch zu audacity kopiert und in einer Datei abgelegt. Anschließend habe ich den patch Befehl ausgeführt. Leider gab es eine Fehlermeldung:

Code:
 /usr/ports]# patch <~/patch.audacity
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- audio/audacity/Makefile.orig        2017-06-13 07:14:24.056835000 +0200
|+++ audio/audacity/Makefile     2017-06-13 06:44:07.693087000 +0200
--------------------------
Patching file audio/audacity/Makefile using Plan A...
patch: **** malformed patch at line 4: # Created by: Marc van Woerkom <3d@FreeBSD.org>

Habe ich da etwas falsch gemacht? Wenn ich in der Patch-Datei Zeile 4 lösche, kommt die nächste Fehlermeldung zu Zeile 6.
 
Füge einfach mal im audacity Port Makefile unter die Zeile:
Code:
USE_GCC=       4.9+
... diese Zeile ein:
Code:
CXXFLAGS+=      -fabi-version=2
Das ist alles was nötig ist damit audacity wieder läuft, nach dem Compilerlauf.

Längere Erklärung dort bei den GNUs:
https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
Bei "6. Changes to the default compiler option for -fabi-version." findet man diesen Schalter für GCC 4.x.

Edit:
Den Patch hänge ich aber auch noch mal in ordentlich rein:
Code:
--- audio/audacity/Makefile.orig        2017-06-13 20:52:23.917308000 +0200
+++ audio/audacity/Makefile     2017-06-13 20:53:04.171308000 +0200
@@ -27,6 +27,7 @@
NLS_CONFIGURE_WITH=    libintl-prefix="${LOCALBASE}"
OPTIONS_SUB=   yes
USE_GCC=       4.9+
+CXXFLAGS+=      -fabi-version=2
USE_WX=                3.0+
WX_COMPS=      wx
INSTALLS_ICONS=        yes
 
@pit234a
Ich habe alle Pakete deinstalliert und neu gebaut mit synth. pkg_libcheck ergabe folgendes Ergebnis:

Code:
...
das sind "kleinere Kleinigkeiten", die du wohl einfach ignorieren kannst. Du kannst auch auf die Suche gehen und vielleicht im Internet zu den einzelnen libs etwas finden und wozu die gehören.
Ich zeige mal was bei mir:
Code:
pit@senyo /:-# find /usr/local -iname "libstdc++.so.*"
/usr/local/lib32/compat/libstdc++.so.6
/usr/local/lib/compat/libstdc++.so.6
/usr/local/lib/opera/libstdc++.so.6
/usr/local/lib/gcc5/libstdc++.so.6
/usr/local/lib/gcc5/libstdc++.so.6.0.21-gdb.py
/usr/local/lib/gcc5/libstdc++.so.6.0.21
pit@senyo /:-# pkg which /usr/local/lib/gcc5/libstdc++.so.6
/usr/local/lib/gcc5/libstdc++.so.6 was installed by package gcc-5.4.0
pit@senyo /:-# ll /usr/local/lib/gcc5/libstdc++.so.6
lrwxr-xr-x  1 root  wheel  19 29 Apr. 04:44 /usr/local/lib/gcc5/libstdc++.so.6 -> libstdc++.so.6.0.21

und ziemlich wichtig:
Code:
pit@senyo ~:- > find /usr/ports -iname "bsdadminscript*"
/usr/ports/ports-mgmt/bsdadminscripts2
/usr/ports/ports-mgmt/bsdadminscripts
bsdadminscripts2 ist aktuell und für das neue pkgng gemacht. Ich habe es nicht in Benutzung, weil ich kaum noch Bedarf sehe, seit ich nur noch Pakete im Einsatz habe. Du solltest darauf achten und das richtige Tool verwenden und dann die man-page dazu studieren. Was ich im Kopf habe, ist die Option -q, die wohl eine Liste von Ports ergibt, die sich direkt auswerten bzw neu installieren lässt. So sollten die meisten Probleme zu lösen sein.

Dass du nur so wenige Fehler überhaupt findest, ist ein sehr gutes Zeichen.
 
Zurück
Oben