• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

audacity ..was für ein lausiger Port?

holm

Well-Known Member
Themenstarter #1
Hat Jemand ne Idee wie ich herausfinde was hier gelinkt wird und stört:
$ audacity

(Audacity:32753): Gtk-ERROR **: 16:47:47.113: GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported
Trace/BPT trap (core dumped)

Ich mache mir nun schon auf FreeBSD 11.2 fast die ganze Woche einen Häßlichen damit dieses Mistding zum laufen zu bekommen.
Auf einem 2. Rechner mit 11.2 läuft das problemlos...

/usr/local/bin/audacity:
libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x8013ac000)
libportaudio.so.2 => /usr/local/lib/libportaudio.so.2 (0x8015d6000)
libsndfile.so.1 => /usr/local/lib/libsndfile.so.1 (0x8017ec000)
libsoxr.so.0 => /usr/local/lib/libsoxr.so.0 (0x801a77000)
libwx_gtk3u_xrc-3.1.so.2 => /usr/local/lib/libwx_gtk3u_xrc-3.1.so.2 (0x801cdd000)
libwx_gtk3u_html-3.1.so.2 => /usr/local/lib/libwx_gtk3u_html-3.1.so.2 (0x801fae000)
libwx_gtk3u_qa-3.1.so.2 => /usr/local/lib/libwx_gtk3u_qa-3.1.so.2 (0x802287000)
libwx_gtk3u_core-3.1.so.2 => /usr/local/lib/libwx_gtk3u_core-3.1.so.2 (0x802600000)
libwx_baseu_xml-3.1.so.2 => /usr/local/lib/libwx_baseu_xml-3.1.so.2 (0x802fd3000)
libwx_baseu_net-3.1.so.2 => /usr/local/lib/libwx_baseu_net-3.1.so.2 (0x8031e5000)
libwx_baseu-3.1.so.2 => /usr/local/lib/libwx_baseu-3.1.so.2 (0x803600000)
libFLAC++.so.6 => /usr/local/lib/libFLAC++.so.6 (0x803ab3000)
libFLAC.so.8 => /usr/local/lib/libFLAC.so.8 (0x803cce000)
libid3tag.so.0 => /usr/local/lib/libid3tag.so.0 (0x803f0e000)
libz.so.6 => /lib/libz.so.6 (0x804129000)
libmad.so.0 => /usr/local/lib/libmad.so.0 (0x804341000)
libm.so.5 => /lib/libm.so.5 (0x804561000)
libSoundTouch.so.1 => /usr/local/lib/libSoundTouch.so.1 (0x804790000)
libtwolame.so.0 => /usr/local/lib/libtwolame.so.0 (0x8049a2000)
libvorbisenc.so.2 => /usr/local/lib/libvorbisenc.so.2 (0x804bc7000)
libvorbisfile.so.3 => /usr/local/lib/libvorbisfile.so.3 (0x804e69000)
libvorbis.so.0 => /usr/local/lib/libvorbis.so.0 (0x805071000)
libogg.so.0 => /usr/local/lib/libogg.so.0 (0x8052a3000)
libvamp-hostsdk.so.3 => /usr/local/lib/libvamp-hostsdk.so.3 (0x8054a9000)
libgtk-3.so.0 => /usr/local/lib/libgtk-3.so.0 (0x805800000)
libgdk-3.so.0 => /usr/local/lib/libgdk-3.so.0 (0x8060f4000)
libpangocairo-1.0.so.0 => /usr/local/lib/libpangocairo-1.0.so.0 (0x8063b7000)
libpango-1.0.so.0 => /usr/local/lib/libpango-1.0.so.0 (0x8065c4000)
libatk-1.0.so.0 => /usr/local/lib/libatk-1.0.so.0 (0x806812000)
libcairo-gobject.so.2 => /usr/local/lib/libcairo-gobject.so.2 (0x806a3d000)
libcairo.so.2 => /usr/local/lib/libcairo.so.2 (0x806c45000)
libthr.so.3 => /lib/libthr.so.3 (0x806f6d000)
libgdk_pixbuf-2.0.so.0 => /usr/local/lib/libgdk_pixbuf-2.0.so.0 (0x807195000)
libgio-2.0.so.0 => /usr/local/lib/libgio-2.0.so.0 (0x8073b8000)
libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0 (0x80774c000)
libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x807997000)
libintl.so.8 => /usr/local/lib/libintl.so.8 (0x807cae000)
libasound.so.2 => /usr/local/lib/libasound.so.2 (0x807eb9000)
libjack.so.0 => /usr/local/lib/libjack.so.0 (0x8081bd000)
librt.so.1 => /usr/lib/librt.so.1 (0x8083dc000)
libc++.so.1 => /usr/lib/libc++.so.1 (0x8085e2000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x8088b0000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x808acf000)
libc.so.7 => /lib/libc.so.7 (0x808cde000)
libgomp.so.1 => /usr/local/lib/gcc8/libgomp.so.1 (0x809096000)
libgthread-2.0.so.0 => /usr/local/lib/libgthread-2.0.so.0 (0x8092c3000)
libX11.so.6 => /usr/local/lib/libX11.so.6 (0x8094c4000)
libXxf86vm.so.1 => /usr/local/lib/libXxf86vm.so.1 (0x809803000)
libSM.so.6 => /usr/local/lib/libSM.so.6 (0x809a07000)
libnotify.so.4 => /usr/local/lib/libnotify.so.4 (0x809c0e000)
libXtst.so.6 => /usr/local/lib/libXtst.so.6 (0x809e15000)
libpangoft2-1.0.so.0 => /usr/local/lib/libpangoft2-1.0.so.0 (0x80a01a000)
libfontconfig.so.1 => /usr/local/lib/libfontconfig.so.1 (0x80a230000)
libfreetype.so.6 => /usr/local/lib/libfreetype.so.6 (0x80a477000)
libpng16.so.16 => /usr/local/lib/libpng16.so.16 (0x80a72f000)
libjpeg.so.8 => /usr/local/lib/libjpeg.so.8 (0x80a96a000)
libtiff.so.5 => /usr/local/lib/libtiff.so.5 (0x80abfd000)
liblzma.so.5 => /usr/lib/liblzma.so.5 (0x80ae77000)
libjbig.so.2 => /usr/local/lib/libjbig.so.2 (0x80b0a0000)
libsecret-1.so.0 => /usr/local/lib/libsecret-1.so.0 (0x80b2ad000)
libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x80b4f7000)
libmspack.so.0 => /usr/local/lib/libmspack.so.0 (0x80b6fa000)
libXinerama.so.1 => /usr/local/lib/libXinerama.so.1 (0x80b910000)
libXrandr.so.2 => /usr/local/lib/libXrandr.so.2 (0x80bb12000)
libXcursor.so.1 => /usr/local/lib/libXcursor.so.1 (0x80bd1c000)
libXext.so.6 => /usr/local/lib/libXext.so.6 (0x80bf27000)
libgmodule-2.0.so.0 => /usr/local/lib/libgmodule-2.0.so.0 (0x80c138000)
libXi.so.6 => /usr/local/lib/libXi.so.6 (0x80c33b000)
libXcomposite.so.1 => /usr/local/lib/libXcomposite.so.1 (0x80c549000)
libXdamage.so.1 => /usr/local/lib/libXdamage.so.1 (0x80c74b000)
libXfixes.so.3 => /usr/local/lib/libXfixes.so.3 (0x80c94d000)
libatk-bridge-2.0.so.0 => /usr/local/lib/libatk-bridge-2.0.so.0 (0x80cb52000)
libepoxy.so.0 => /usr/local/lib/libepoxy.so.0 (0x80cd82000)
libfribidi.so.0 => /usr/local/lib/libfribidi.so.0 (0x80d091000)
libharfbuzz.so.0 => /usr/local/lib/libharfbuzz.so.0 (0x80d2a7000)
libpixman-1.so.0 => /usr/local/lib/libpixman-1.so.0 (0x80d589000)
libEGL.so.1 => /usr/local/lib/libEGL-NVIDIA.so.1 (0x80d853000)
libxcb-shm.so.0 => /usr/local/lib/libxcb-shm.so.0 (0x80db55000)
libxcb.so.1 => /usr/local/lib/libxcb.so.1 (0x80dd57000)
libxcb-render.so.0 => /usr/local/lib/libxcb-render.so.0 (0x80df7d000)
libXrender.so.1 => /usr/local/lib/libXrender.so.1 (0x80e18a000)
libGL.so.1 => /usr/local/lib/libGL-NVIDIA.so.1 (0x80e393000)
libffi.so.6 => /usr/local/lib/libffi.so.6 (0x80e6be000)
libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x80e8c5000)
libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x80ebc0000)
libdb-5.3.so.0 => /usr/local/lib/libdb-5.3.so.0 (0x80ee5e000)
libdl.so.1 => /usr/lib/libdl.so.1 (0x80f1f3000)
libICE.so.6 => /usr/local/lib/libICE.so.6 (0x80f3f4000)
libbz2.so.4 => /usr/lib/libbz2.so.4 (0x80f60d000)
libgcrypt.so.20 => /usr/local/lib/libgcrypt.so.20 (0x80f821000)
libgpg-error.so.0 => /usr/local/lib/libgpg-error.so.0 (0x80fb48000)
libelf.so.2 => /lib/libelf.so.2 (0x80fd67000)
libdbus-1.so.3 => /usr/local/lib/libdbus-1.so.3 (0x80ff7f000)
libatspi.so.0 => /usr/local/lib/libatspi.so.0 (0x8101d0000)
libgraphite2.so.3 => /usr/local/lib/libgraphite2.so.3 (0x810401000)
libnvidia-glsi.so.1 => /usr/local/lib/libnvidia-glsi.so.1 (0x81062a000)
libXau.so.6 => /usr/local/lib/libXau.so.6 (0x8108af000)
libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0x810ab2000)
libnvidia-tls.so.1 => /usr/local/lib/libnvidia-tls.so.1 (0x810cb7000)
libnvidia-glcore.so.1 => /usr/local/lib/libnvidia-glcore.so.1 (0x811000000)
$

Gruß,
Holm
 

Lance

Well-Known Member
#3
Da würde einem sowas wie Flatpack gerade recht kommen. Ich weiss das hier oft viele argwöhnisch auf (Linux-) Neuerungen schauen, aber diese Abhängigkeitsprobleme nerven!
Ist sowas ähnliches wie Flatpack in der Planung oder im Gespräch?
 

-Nuke-

Well-Known Member
#4
Ich hab zwar jetzt vom konkreten Problem keine Ahnung, aber das Problem selbst wird vermutlich eher im x11-toolkits/wxgtk31 Port liegen.
 

klimaschreck

Well-Known Member
#5
x11-toolkits/wxgtk31 habe ich zuerst die Optionen verändert und ohne GTK aus den Ports gebaut. Das hat nichts gebracht. Es klapppte bei mir erst als ich gtk2 entfernt habe. Das gibt dann zwar Konflikte mit anderen Paketen. Insofern deinstalliere ich es bevor ich audacity nutze, anschließend füge gtk2 wieder hinzu.
 

pit234a

Well-Known Member
#6
ich kann auch nur ganz allgemein etwas dazu sagen.
Solche Probleme sind nicht FreeBSD-typisch. Sie entstehen meist, wenn nicht alles auf dem System aktuell gehalten wird. Wer mit ports leben will, muss regelmäßig den portstree aktualisieren bevor er etwas baut und dann mittels eines üblichen Tools wie portupgrade (portmaster?) alle installierten Ports auch updaten.
Probleme mit fehlerhaften Libs sind fast immer auf schnelle und unvollständige Änderungen an installierter SW zurück zu führen.
Es gab früher das Tool pkg_libcheck oder so ähnlich, das bei der Prüfung und Auflösung solcher Abhängigkeiten gute Dienste leisten konnte.
Man sieht schon, dass ich alle diese Tools nur noch aus der Vergangenheit erinnere. Schon lange wende ich sie nicht mehr praktisch an, weil es mit Paketen sehr viel einfacher und zuverlässiger geht. Ich behaupte mal, dass ein System mit pkgng aufgebaut und verwaltet, keinerlei derartige Probleme mehr zulässt.
Trotzdem kann es hier mal zu kurzfristigen Problemen mit Versionen kommen, wenn es ein "böses" Paket mal auf den Server geschafft hat. Gerade, weil immer mehr Ports ohne Maintainer sind, kann ich mir hier Engpässe vorstellen.

Und es hört sich zwar wie eine immer gleiche Ausrede an: FreeBSD und die Port-Maintainer haben einfach nicht die Möglichkeiten, hier immer perfekte Lösungen zu bieten. Wenn die Tendenz anhält, könnte das dazu führen, dass FreeBSD als Desktop-System unbrauchbar wird. Ich habe dabei das Bild einer Pflanze im Kopf, die nicht mehr gegossen wird und deshalb langsam eingeht.
Die Evolution in der IT könnte zum Untergang von FreeBSD führen, oder es auf Nischen drängen, wo Desktop-Anwendungen keine Rolle mehr spielen.

Ich sage das nun nicht, um eine neue Diskussion anzuregen. Sondern weil die Ausgangsfrage "was für ein lausiger Port?" diese Gedanken in mir aufsteigen lassen.
 

SolarCatcher

Well-Known Member
#7
Da würde einem sowas wie Flatpack gerade recht kommen. Ich weiss das hier oft viele argwöhnisch auf (Linux-) Neuerungen schauen, aber diese Abhängigkeitsprobleme nerven!
Ist sowas ähnliches wie Flatpack in der Planung oder im Gespräch?
PC-BSD hatte das mal mit seinem PBI-Paketen - die sollten genau das machen und brachten alle Abhängigkeiten mit. Hat sich aber nicht durchgesetzt und ich bin nicht traurig darüber. Denn dann muss man nicht mehr nur der Distro sondern auch noch dem Paket-Betreuer vertrauen, dass er schon immer alles aktuell hält. Ist ein ähnliches Problem wie bei all den Docker-Images. Und wenn es mal wieder ein Problem mit z.B. OpenSSL gibt, muss jedes zweite (Flatpack-)Paket komplett neu heruntergeladen und installiert werden, anstatt nur OpenSSL zu aktualisieren.
 

-Nuke-

Well-Known Member
#8
Und wenn es mal wieder ein Problem mit z.B. OpenSSL gibt, muss jedes zweite (Flatpack-)Paket komplett neu heruntergeladen und installiert werden, anstatt nur OpenSSL zu aktualisieren.
Das stimmt nicht. Flatpak hat Runtime-Pakete mit den grundlegenden Abhängigkeiten, die sich alle Flatpaks teilen. Flatpaks von Anwendungen selbst liefern nur das mit, was die Runtime nicht bietet. Weiterhin muss man Pakete nicht "komplett neu" herunterladen. Das funktioniert alles über OSTree. Man lädt immer nur Deltas runter.
 

SolarCatcher

Well-Known Member
#9
@-Nuke- Danke, dann hatte ich die Flatpack website zu schnell überflogen. Ich laß von "easy to bundle... libraries with your own app".

Dann allerdings müsste das Problem doch auch hier dasselbe sein wie beim OP: Wenn ein Port-/Paket-Maintainer seine Software nicht in Sync hält mit dem System darunter, habe ich ein Problem - egal ob das System darunter ein BSD, ein GNU/Linux oder Flatpack ist... oder verstehe ich das falsch?
 

Lance

Well-Known Member
#10
macOS ist doch auch ein Unix und die Anwendungen kommen alle mit ihren Abhängigkeiten daher und lassen sich meist ohne Installation direkt starten. Frisst zwar mehr Speicherplatz aber es ist sehr anwenderfreundlich und funktioniert! Linux versucht es ähnlich mit Flatpack, AppImage (z. B. das Tool "Etcher") und Co. aber hin und wieder funktionieren z.B. die AppImages nicht da doch irgendwelche Libs fehlen. Ich bezweifle aufgrund der Distributionenvielfalt (Debian, Arch, RedHat usw.) dass es jemals so gut funktionieren wird.

FreeBSD hat dieses Distributionsvielfalt-Problem nicht und es sollte doch auch hier sowas wie beim macOS möglich sein. Aber wenn das eben nicht so gewollt ist dann ist es halt zu akzeptieren und man sollte sich halt wirklich überlegen ob FreeBSD auf oder als Desktop im Vgl zur Konkurrenz überhaupt (noch) Sinn macht.
Entweder ich bleibe stur bei meiner Linie und friste ein Nieschendasein und hinke der Konkurrenz immer mehr hinterher oder ich mache das OS Anwenderfreundlicher für eine breitere Masse, was dann evtl mehr Entwickler anlockt und letztenendes dem OS zugute kommt, oder nicht? Aber ich möchte hier nicht zu sehr abweichen, dafür gibts ja hier einen anderen Thread.
 

-Nuke-

Well-Known Member
#11
Dann allerdings müsste das Problem doch auch hier dasselbe sein wie beim OP: Wenn ein Port-/Paket-Maintainer seine Software nicht in Sync hält mit dem System darunter, habe ich ein Problem - egal ob das System darunter ein BSD, ein GNU/Linux oder Flatpack ist... oder verstehe ich das falsch?
Es kann natürlich Probleme geben. Flatpak selbst testet aber sämtliche Runtime-Updates auf ABI Breaks. Und es wird von einem Paketmaintainer auch erwartet, dass er sein Flatpak auch testet, dass es funktioniert. Bei FreeBSD wird ja nur ein Build-Skript ausgeliefert und es testet im Grunde niemand, ob das Paket auch in allen Konstellationen wirklich funktioniert. Sieht man hier ja. Das Problem hast du bei Ansätzen wie Flatpak nicht, da es nur eine einzige Konfiguration gibt und so ziemlich alle Probleme lassen sich auf eine Ursache (ein Problem in der Runtime) zurückführen.

Das ganze funktioniert in etwa wie bei Android. Dort programmiert man ja Software auch gegen eine spezifische Runtime-Version.

So, aber um mal On-Topic zu werden:

@holm
Ändert sich was wenn du STATIC_WX in den Port-Optionen von Audacity aktivierst?
 

SolarCatcher

Well-Known Member
#12
Danke für die Erkläfung, @-Nuke- .

@holm
Wenn das auf einem Rechner funktioniert und auf dem anderen nicht, liegt es doch vermutlich nicht an dem Paket selbst, sondern daran, dass noch irgendwo ältere Libraries rumhängen, die nicht passen (meine Vermutung!). Wenn ich solche Probleme hatte, habe ich die eigentlich jedes Mal mit einem pkg clean -a gefolgt von einem pkg upgrade -f lösen können.
 
H

holgerw

Guest
#13
Hmm, Audacity ist in beruflicher Hinsicht eine sehr wichtige Anwendung für mich.
Und sie funktioniert seit meinem Umstieg auf FreeBSD vor zwei Jahren immer reibungslos, sei es, dass ich Audacity aus den Ports baue, sei es, dass ich es als Binary installiere.
Ich kann diese Jereminaden - auch im Hinblick auf FreeBSD als ungeeignet für den Desktop - überhaupt nicht nachvollziehen.
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#14
Das Problem sind einfach beschissene Build-Systeme - um es mal deutlich zu sagen - die nicht benötigte Bibliotheken fälschlicherweise als Abhängigkeit aufgreifen und einbinden. Gerade das gute und leider Gottes nicht totzukriegende Autobreak (in weniger erfahrenen Kreisen auch Automake genannt) ist da berüchtigt für... Die wirksamste Lösung ist in garantiert sauberen Umgebungen, wie zum Beispiel Poudriere sie nutzt, zu bauen.
 

holm

Well-Known Member
Themenstarter #17
Ich hatte die Ports mit svn aktualisiert und ich hatte auch kräftig ausgeräumt und Ports neu gebaut bei meinen Versuchen.
Ätzend ist die Fehlermeldung, ich weiß nicht welcher Idiot das gebaut hat, aber ein Hinweis welches Symbol da betroffen ist wäre doch wohl das Mindeste? So liest sich das wie "Error 47 verdammte Scheiße nochmal!", da kanns ja wohl nicht sein.
Dein PKG Lösung ist für mich unbrauchbar Pit, weil ich z.B. regelmäßig kicad-devel mit der Git Version baue und auch benutze.
Das Deinstallieren von GTK2 um den Mist bauen zu können ist keine Problemlösung, das vertreibt nur das Problem.
Neu in Bezug auf audacity ist wohl, das es x11-toolkits/wxgtk31 explizit fordert..auf die Weise werden die Probleme reingezogen, Kicad braucht immer noch wxgtk30 parallel. Ich denke mal das Problem kann auch Poudriere nicht lösen.
Ich habe das Problem mit Audacity unter Windows auf einem Notebook erst mal vertrieben, hoffe aber das irgendwann mal auflösen zu können. Bis dahin bleibt die Software oder ihr Port einfach eine Krankheit.

Gruß,

Holm
 
H

holgerw

Guest
#18
Hallo @holm

nun könntest Du vielleicht mal den Committer anmailen, vielleicht hat der auch ein Interesse daran, seinem Port solche "Krankheiten" auszutreiben.

Bei xfburn, was unter der "Krankheit" litt, einfach keine Audio-CDs zusammenstellen zu können und dabei ständig abstürzte, hat eine beherzte Anfrage beim Committer z.B. zum Bugfix geführt.
 

holm

Well-Known Member
Themenstarter #19
Ja freilich. Ich habe gerade angestoßen den Kram den pkg_libcheck zu Tage fördert neu zu bauen, danach versuche ichs nochmal und dann kommt der Bugreport.

Gruß,

Holm
 
H

holgerw

Guest
#20
Hab mal gerade poudriere angeworfen, nutze eine 12.0-RELEASE-Jail und den Head-Branch.
In der Buildliste hab ich nur audio/audacity und cad/kicad-devel, an den Options hab ich nichts rumgefummelt.

Bin mal gespannt auf das Resultat, er baut schon fleißig :)

Heute Nachmittag mehr, ich bin nun erstmal unterwegs.
 

holm

Well-Known Member
Themenstarter #21
Das ist beim Kicad nur die halbe Miete.. im Makefile versteckt sich da was:

Code:
# Updating to new rev:
# sh files/newVersion.sh
# make makesum && make clean
# make install #breaks probably due to plist differences
# make makeplist > pkg-plist #One has to edit/review the generated plist
# make generate-plist && make check-plist
# < Check PLIST_FILE_LIST below >
Das holt die letzte git Version und baut das.

Gruß,

Holm
 
H

holgerw

Guest
#22
Hallo,

der Kram hat mit poudriere zumindest komplett durch gebaut:
kicad-devel-r20190308190408_8.txz
audacity-2.3.1.txz

Beides lässt sich mit pkg add sauber meinem System hinzu fügen und es existieren nun auch wx30-gtk3 und wx31-gtk3 nebeneinander auf meinem System.

Mehr kann ich Dir leider (momentan) nicht weiter helfen.

P.S.: Beide Anwendungen starten übrigens auch.