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

[Elwood]

Zitat von Florian88

Ich weiss zwar, was es bewirken soll, aber Ich verstehe die Syntax nicht. War das nur ein Tippfehler und du meintest:

pkg_libchk -qo > pkg || portmaster `cat 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 ;-)

me too, ich bin bei Yamagi auch vorsichtig lol

pkg_libchk -qo > pkg ; portmaster `cat pkg`

war vermutlich gemeint?!

[Yamagi]

Zitat von Florian88

War das nur ein Tippfehler

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

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.

[SolarCatcher]

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:

/libexec/ld-elf.so.1: /usr/local/sbin/httpd: Undefined symbol "pcre_info"

[NeoVanGoth]

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. :-/

[Sampaguita]

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:

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:

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

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

ldd /usr/local/bin/php

/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.

[Columbo0815]

Was gibt pkg_libchk (zu finden in /usr/ports/sysutils/bsdadminscripts) aus?

[Sampaguita]

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.

[ralli]

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.

[shakky4711]

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

[Kamikaze]

Mach stattdessen lieber einen Eintrag in der libmap.conf. Die findet man später noch wieder wenn man mal aufräumt.

[Crest]

Das lässt ja schlimmes erahnen darüber wie selten manche FreeBSDler ihre Systeme updaten.

[ralli]

Zitat von Crest

Das lässt ja schlimmes erahnen darüber wie selten manche FreeBSDler ihre Systeme updaten.

Crest und wenn Du mich Depp damit meinst, dann liegst Du goldrichtig.

Jetzt habe ich alles neu installiert und auch die Aktualiserung der ports nicht vergessen.

Und alles funktioniert ohne workaround einwandfrei. Danke für Deine Botschaft!

[shakky4711]

Das lässt ja schlimmes erahnen darüber wie selten manche FreeBSDler ihre Systeme updaten

Das möchte ich jetzt so nicht im Raume stehen lassen. Zu einem ist es ein großer Unterschied ob da irgendwo an vorderster Front ein Web/Mailserver steht, der pausenlos unter Dauerbeschuss liegt, oder zu Hause ein kleiner Dateiserver der die heimische Musikanlage mit Musik und Videos bestreamt.

Ein "freebsd-update" des Betriebssystems mach ich regelmäßig, aber ich sehe offen gesagt keine zwingende Notwendigkeit ständig hier alle Ports neu zu bauen bloß weil eine neue Version neue Features bietet, die ich aber gar nicht benötige. So lange es keine Sicherheitslücken zu stopfen gilt, ist es mir in unkritischen Bereichen recht egal ob ein Programm zum jpeg Dateien prüfen die Nummer 0.8.7 oder 0.8.5 trägt, oder mp3val in der 1.2a oder 1.2.d werkelt...

Aber scheinbar ist es wohl doch ein Unterschied Ports zu aktualisieren, oder (mit gleichen Einstellungen) frisch zu bauen, ich hätte bisher Stein und Bein darauf gewettet dass das Ergebnis eigentlich das Gleiche sein müsste, überrascht mich doch schon wieder dass dem nicht so ist.

Gruß
Shakky

[ralli]

Es gibt ja verschiedene Update- oder Aktualisierungsstrategien. Ich bin nach dem Handbuch vorgegangen und habe

portsnap fetch

portsnap extract

angewendet. Wenn ich mich recht erinnere hatte Kamikaze mal einen Beitrag, wie er wöchentlich sein System aktuell hält. Aber auch nach zeitaufwendiger Suche habe ich den Beitrag nicht wiedergefunden.

Normalerweise sollte doch ein System nach der Grundinstallation stabil laufen. Ist aber wohl nicht so , wie ich jetzt aus leidvoller eigener Erfahrung feststellen musste.

Allerdings ist ein Port Schnappschuss und dessen Auffrischung auch kein Akt.

[Crest]

shakky4711: Was du übersiehst das es seit dem duzende Sicherheitsprobleme in extrem üblichen Ports gab. Es ist also ein echtes Sicherheitslücken ignoriert und nicht bloß hat nicht präventiv aktualisiert und bekanntlich zieht sich nur der den Schuh an dem er passt.