prce-8.30: Shared object "libpcre.so.0" not found, required by "libgtk-x11-2.0.so.0"

Fusselbär

Fusselbär

Makefile Voyeur
Der Bär ist da mit Anlauf in das prce-8.30 Update reingetapst.
Das verhinderte die Benutzung von x11-toolkits/gtk20 Anwendungen, wie etwa Firefox und Chromium Webbrowser.

Inzwischen gibt es in UPDATING den Hinweise alte shared Libs doch besser zu bewahren.
Habe ich natürlich nicht gemacht, weil ich da schon vor dem Eintrag in UPDATING fröhlich mit portupgrade -au drauf gehalten habe. :ugly:

So behebt man das Malheur vorläufig mit Hilfe des FreeBSD libmap Features, um etwa wieder den Firefox oder den Chromium benutzten zu können:
Code: 
[libgtk-x11-2.0.so.0]
libpcre.so.0    libpcre.so.1 # pcre-8.30 Workaround for x11-toolkits/gtk20
in die /etc/libmap.conf eintragen.
Wenn es ein Update für x11-toolkits/gtk20 gibt, einfach wieder raus nehmen.
 
kai_001 schrieb:
dito ... habs dann mit pkg_libchk "sauber" gelöst :-)
Zum Vergrößern anklicken....

Dankeschön für die Anregung, ich hatte es gestern schon mit
Code: 
portupgrade -rfu devel/pcre
mehrfach versucht, aber x11-toolkits/gtk20 erwies sich als hartnäckig und suchte beim installieren immer nach der libpcre.so.0, die es nicht fand und somit scheiterte.

Ich installiere dann mal die sysutils/bsdadminscripts und versuche es dann mit:
Code: 
pkg_libchk -q | xargs -o portupgrade -fu
Mal gucken was dann passiert. :)
 
Bei mir läuft gerade ein:
Code: 
pkg_libchk -qo > pkg | portmaster `pkg`
Bisher sieht es gut aus. Auch noch mal danke an Kamikaze für dieses wirklich sehr hilfreiche Tool. Es macht die Arbeit wirklich einfacher.
 
Argh! :ugly:
x11-toolkits/gtk20 ließ sich nach Neubau immer noch nicht installieren.
Nun bin ich aber auf einer heißen Spur. Es hat sich wohl das Eingabemodul von textproc/ibus als Abhängigkeit eingesammelt,
was wiederum unbedingt die libpcre.so.0 haben will. Davon lässt es sich auch ibus bei Neubau nicht abbringen.
FreeBSD, das ist besser als jeder Krimi! :ugly:
 
Yamagi schrieb:
Bei mir läuft gerade ein:
Code: 
pkg_libchk -qo > pkg | portmaster `pkg`
Bisher sieht es gut aus. Auch noch mal danke an Kamikaze für dieses wirklich sehr hilfreiche Tool. Es macht die Arbeit wirklich einfacher.
Zum Vergrößern anklicken....
Vermutlich bist du inzwischen durch, richtig? Kleiner Tipp: Eben kam ein Update für pcre-8.30... :ugly:
 
Zuletzt bearbeitet:
Ja, es ist durch. Ging problemlos. Mit weiteren Updates warte ich nun aber erstmal. *debil grins*
 
net/avahi-app bestand ebenfalls unbedingt auf die libpcre.so.0 trotz Neubau beim installieren.
Habe das kurzfristig ebenfalls mit der /etc/libmap.conf gelöst:
Code: 
[libavahi-glib.so.1]
libpcre.so.0    libpcre.so.1 # pcre-8.30 Workaround for net/avahi-app
Nachdem dann das neu gebaute net/avahi-app installiert war, habe ich den Eintrag in der /etc/libmap.conf wieder heraus genommen.
Danach ließ sich dann net/avahi-app neubauen und installieren ohne auf die libpcre.so.0 zu bestehen.

So, dann kann es ja gleich weiter gehen, gleich mal fröhlich csup machen, heute wird die Bude mit der CPU beheizt. ;)
 
Was ist eigentlich gegen das Anlegen eines neuen Links auf die Lib zu sagen?
Ich mach das bis jetzt nämlich so, weil ich bis jetzt nicht wusste das es libmap gibt :D
 
Hast du im Überblick wo du das überall gemacht hast? Ich wollte mir das nicht merken wollen. Ich will so wenig Gefuddel wie möglich haben... ;)
 
Hi,

Die Lösung mit pkg_libchk -qc | xargs -o portupgrade -fu gestern hat gut funktioniert. Trotzdem ist es bärig lästig und nochmal müsste das die Woche nicht sein :)

Gruß Bummibär
 
Naja im überblick habe ich das nicht aber die paar kb kann ich verkraften :)
Ich sehe aber den Vorteil und nehme das nächste mal libmap.
pkg_libchk habe ich auch benutzt nur wie Fusselbär schon gesagt hat, ibus will libpcre.so.0 haben :(
 
Yamagi schrieb:
Bei mir läuft gerade ein:
Code: 
pkg_libchk -qo > pkg | portmaster `pkg`
Zum Vergrößern anklicken....

Ich weiss zwar, was es bewirken soll, aber Ich verstehe die Syntax nicht. War das nur ein Tippfehler und du meintest:
Code: 
pkg_libchk -qo > pkg [B]||[/B] portmaster `[B]cat[/B] pkg`

Oder war das irgendeine Pipe-Magie, die ich noch nicht kenne?

Die Frage ist nicht ironisch gemeint, kann mir vorstellen, dass Yamagi wieder irgendeinen Trick kennt ;-)
 
Florian88 schrieb:
Ich weiss zwar, was es bewirken soll, aber Ich verstehe die Syntax nicht. War das nur ein Tippfehler und du meintest:
Code: 
pkg_libchk -qo > pkg [B]||[/B] portmaster `[B]cat[/B] pkg`

Oder war das irgendeine Pipe-Magie, die ich noch nicht kenne?

Die Frage ist nicht ironisch gemeint, kann mir vorstellen, dass Yamagi wieder irgendeinen Trick kennt ;-)
Zum Vergrößern anklicken....

me too, ich bin bei Yamagi auch vorsichtig :) lol

Code: 
pkg_libchk -qo > pkg [B];[/B] portmaster `[B]cat[/B] pkg`

war vermutlich gemeint?!
 
Florian88 schrieb:
War das nur ein Tippfehler
Zum Vergrößern anklicken....

Das war tatsächlich übelst vertippt. Korrekt ist natürlich:

Code: 
pkg_libchk -qo > pkg ; portmaster `cat pkg`

Den Umweg über eine Datei nehme ich, um nachvollziehen zu können, was neu gebaut wurde oder wird. Meist ist es nicht nötig, aber im Fehlerfall kann es ab und an helfen.
 
Danke, Fusselbär. Das mit der libmap kannte ich noch nicht und habe solche Probleme auch immer wie ath0 gelöst (Softlink). Mit libmap ist das natürlich schicker!

Allerdings beschwert sich noch der Apache über irgendein Problem mit pcre. Weiß jemand, ob das auch mit der Library zu tun hat:
Code: 
/libexec/ld-elf.so.1: /usr/local/sbin/httpd: Undefined symbol "pcre_info"
 
Ich bin gerade dank dem selben Problem über diesen Thread gestoßen, in meinem Fall war php5, apache22 und postfix nach dem Upgrade auf pcre-8.30 kaputt.

Ich hatte es auch auf die quick'n'dirty Art versucht indem ich einfach einen Symlink von libpcre.so.0 auf die neue libpcre.so.1 gesetzt habe, allerdings mit dem selben Ergebnis wie SolarCatcher, ergo beim Aufruf von php die Meldung 'Undefined symbol "pcre_info"'.

Da SolarCatcher keine Antwort mehr bekommen hat, gehe ich davon aus, dass sich das Problem mittlerweile gelöst hat. Falls aber jemand mit dem selben Problem über den Thread stolpert:

Es reicht nicht aus, einen Symlink zu setzen! Allerdings braucht man die libpcre.so.0 nicht. Die davon abhängigen Packages müssen einfach neu compiliert werden. Dabei ist zu beachten, dass php5 einen funktionierenden Apache voraussetzt, d.h. zuerst apache22, dann php5.

Einziges verbleibendes Problem: Postfix ist aktuell als broken markiert und lässt sich nicht so einfach aus dem Port bauen. :-/
 
Gleiches Problem bei mir, auch in Verbindung mit apache22 und php5 (5.3.10).

Ich habe einen Server mittels portmaster aktualisiert (aktueller apache, mysql und php) doch leider streikt nun php beim Aufruf von apachectl -t:
Code: 
httpd: Syntax error on line 105 of /usr/local/etc/apache22/httpd.conf: Cannot load /usr/local/libexec/apache22/libphp5.so into server: Shared object "libpcre.so.0" not found, required by "libphp5.so"

Stelle ich mittels libmap.conf den Pfad um (libpcre.so.0 libpcre.so.1) erhalte ich folgende Meldung:
Code: 
httpd: Syntax error on line 105 of /usr/local/etc/apache22/httpd.conf: Cannot load /usr/local/libexec/apache22/libphp5.so into server: /usr/local/libexec/apache22/libphp5.so: Undefined symbol "pcre_info"

ldd /usr/local/libexec/apache22/libphp5.so
Code: 
/usr/local/libexec/apache22/libphp5.so:
...
        libpcre.so.0 => not found (0x0)
...

ldd /usr/local/bin/php
Code: 
/usr/local/bin/php:
...
        libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x28327000)
...

Ich habe mittlerweile PCRE mehrfach komplett neu aufgebaut; sogar mit portmaster -r mitsamt aller Anhängigkeiten zuvor entfernt. Gleiches gilt für Apache und PHP5. Ich bin mittlerweile ziemlich ratlos. ;'(
 
Die Ausgabe von pkg_libchk bleibt komplett leer (sowohl auf Konsole als auch bei Ausgabe in eine Datei). Ich habe die Optionen -a, -r und -qo (siehe Zeile von Yamagi) ausprobiert.
 
Ich habe gerade Bekanntschaft mit dem obigen Problem gemacht, habe dann recherchiert und bin auf diesen Thread gestoßen.
Weil ich (auch) ein Liebhaber älterer Software und Programmiersprachen bin, hatte ich FreeBSD 9 neu mit dem Windows Manager von openmotif mwm installiert. Und plötzlich konnte ich leafpad nicht mehr starten, auch mein nvidia-settings bockte, es schienen ausschließlich GTK Programme zu sein, die die Mitarbeit verweigerten. Dann habe ich diesen Workaround ausprobiert, was bei mir aber keine Besserung brachte. Vorher mit FreeBSD 9 und fluxbox gab es dieses Problem nicht. Ich möchte noch hinzufügen, das ich die ports nach der Installation noch nicht aktualisierte. Wäre das Problem dann behoben gewesen? Augenblicklich bin ich wieder mit Debian Squeeze unterwegs, weil ich ja arbeitsfähig bleiben will und muss. Wenn es dafür keine Lösung gibt, muss ich mich wohl gedulden, bis die Version 9.1 am 17. August 2012 veröffentlicht wird. Das wird dann mein Glückstag, auch weil ich an diesem Datum vor 62 Jahren geboren wurde.;)
 
Hallo Ralli,

mich hat die Falle vor 2 Wochen erwischt, bei meinen installierten Paketen hat es genügt unter
/usr/local/lib/ einen Softlink mit dem Namen libpcre.so.0 zu erstellen der auf die libpcre.so.1 zeigt.

Die Lösung hatte ich hier gefunden: http://forums.freebsd.org/showthread.php?t=29858

Andere Tips, z.B. den Neubau aller Ports zu erzwingen, hatten nichts gebracht.

Gruß
Shakky
 
Mach stattdessen lieber einen Eintrag in der libmap.conf. Die findet man später noch wieder wenn man mal aufräumt.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben