PHP Fatal error: Class 'PDO' not found - obwohl im Binary einkompiliert

[MartinSNippes]

Hallo Team,

eigentlich musste ich mich mit PHP bisher nicht besonders beschäftigen, eines der notwendigen Pakete in meinem OpenSuse Server Universe.

"Never change a running system" kommt nicht von ungefähr, leider führte es bei mir zu einer mittleren Katastrophe.

Ich wollte auf meinem Linux Server über das source rpm auf eine aktuellere Version wechseln "7.4.27" (neuer geht nicht, da andere Software noch nicht mit
Version 8.x arbeitet), leider begannen nach der Installation sämtliche Probleme...


PHP Skripte werden nicht ausgeführt, sondern ich erhalte z. B.

[Mon Jan 24 12:32:52.255040 2022] [php7:error] [pid 29759] [client 127.0.0.1:50738] PHP Fatal error: Uncaught Error: Class 'PDO' not found in /srv/www/htdocs/owncloud/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/DriverManager.php:270\nStack trace:\n#0 /srv/www/htdocs/owncloud/lib/private/DB/ConnectionFactory.php(139): Doctrine\\DBAL\\DriverManager::getConnection()\n#1 /srv/www/htdocs/owncloud/lib/private/Server.php(552): OC\\DB\\ConnectionFactory->getConnection()\n#2 /srv/www/htdocs/owncloud/lib/composer/pimple/pimple/src/Pimple/Container.php(11: OC\\Server->OC\\{closure}()\n#3 /srv/www/htdocs/owncloud/lib/private/AppFramework/Utility/SimpleContainer.php(10: Pimple\\Container->offsetGet()\n#4 /srv/www/htdocs/owncloud/lib/private/ServerContainer.php(86): OC\\AppFramework\\Utility\\SimpleContainer->query()\n#5 /srv/www/htdocs/owncloud/lib/private/Server.php(1259): OC\\ServerContainer->query()\n#6 /srv/www/htdocs/owncloud/lib/private/Server.php(256): OC\\Server->getDatabaseConnection()\n#7 /srv/www/htdocs/owncloud/lib/composer/pimple/pimple/src/Pimple/Container.php(11: OC\\Server->OC\\{closure}()\n#8 /srv/www/htdocs/owncloud/lib in /srv/www/htdocs/owncloud/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/DriverManager.php on line 270


Das ist eine Fehlermeldung, wenn ich mich auf meinem Owncloud Server anmelden möchte, allerdings erhalte ich die Fehlermeldung auch bei anderen Applikationen (Nextcloud, BareOs, roundcubemail), nichts, was PHP voraussetzt, funktioniert.

Allerdings sehe ich in den Apache error logs wiederholt, dass die PDO Klasse nicht gefunden wird.



Nun habe ich versucht, PDO in das PHP Binary zu kompilieren, was auch bautechnisch wunderbar funktioniert:


$ "php -m" zeigt mir

--
[PHP Modules]
bcmath
bz2
calendar
Core
ctype
curl
date
dba
dom
enchant
exif
fileinfo
filter
ftp
gd
gettext
gmp
hash
iconv
intl
json
ldap
libxml
mbstring
mysqli
mysqlnd
odbc
openssl
pcntl
pcre
PDO
pdo_mysql
PDO_ODBC
pdo_pgsql
pdo_sqlite
pgsql
Phar
posix
readline
Reflection
session
shmop
SimpleXML
snmp
soap
sockets
sodium
SPL
sqlite3
standard
sysvmsg
sysvsem
sysvshm
tidy
tokenizer
xml
xmlreader
xmlrpc
xmlwriter
xsl
zip
zlib

[Zend Modules]
--

Das Modul "PDO" ist offensichtlich dabei!

Nun frage ich mich, weswegen erhalte ich die Fehlermeldung vom Apache (neueste Version): "PHP Fatal error: Uncaught Error: Class 'PDO' not found"


Muss ich denn das Modul im PHP-Binary "aktivieren"?


Mit dem Bau der Version 7.4.27 habe ich auch ein "make test" durchgeführt, ohne irgendwelche Fehler.

Leider kann ich (und möchte auch nicht) auf die alte Version 7.3.23 downgraden (u. a. Sicherheitsaspekte).


Noch ganz wichtig. In der Log-Datei "/var/log/php_errors.log", welche Fehler protokollieren sollte (habe ich auch getestet, dass das funktioniert) wird
kein Fehler und auch keine Warnung angegeben.



Über die Seite

https://www.xy-space.de/test.php

ist meine PHP Version mit Detailinformationen zu finden.

Danke im Voraus! Kann ich dieses Binary noch anderweitig testen? Was habe ich für Möglichkeiten?


Noch ein kurzer Nachtrag: sämtliche Applikationen (nextcloud, owncloud, roundcubemail, bareos) hatten vor dem Versionsupgrade funktioniert, an diesen Anwendungen ist
überhaupt nichts verändert worden, auch die Apache-Konfigurationsdateien wurden überhaupt nicht verändert.
Alle Web-Applikationen, die kein PHP benötigen funktionieren!

"a2enmod -l" zeigt mir u. a. die Module "php7 php7.4"



Und noch ein Nachtrag: Anfänglich hatte ich die Module als Extension nicht im Binary, sondern separat. Damals erhielt ich allerdings "unresolved symbols", und deswegen dachte ich, dass ich mit
den Modulen im Binärprogramm besser dran bin (Trugschluss?). Diese "unresolved symbols" ließen sich auch nicht durch Wechsel des Compilers (gcc, icc, clang) vermeiden.
Sämtliche Software gibt es nur ein einziges Mal im System, keine doppelten Bibliotheken oder Header Files...


Und noch ein Nachtrag: Ich muss php aus den Quellen kompilieren, da ich die Binär-rpm aufgrund einer älteren glibc nicht nutzen kann.

[tomBuilder]

$ "php -m" zeigt mir

das ist die cli version - falls es eine andere ini gibt nutze doch

https://www.php.net/manual/de/function.phpinfo.php

also eine webseite mit nur

<?php

phpinfo( );

[MartinSNippes]

Also, über


https://www.xy-space.de/test.php


ist meine PHP Version mit Detailinformationen zu finden.

Unter "Additional Modules" finde ich keinen Eintrag, wohl weil alle Module im Binärprogramm einkompiliert sind?

Martin.

[tomBuilder]

Also, über


https://www.xy-space.de/test.php


ist meine PHP Version mit Detailinformationen zu finden.

Unter "Additional Modules" finde ich keinen Eintrag, wohl weil alle Module im Binärprogramm einkompiliert sind?

Martin.

das wäre mir neu, stehen denn andere eincomp module dort drin ?
wieso steht es dann in der cli version ?
das mit der .ini überlesen - sollte eingetniss ausführlich erklärt sein beim compilieren ?
wieso comp du php selbst ?

https://www.opensuse-forum.de/thread...ter-suse-15-3/

urls von mitforisten rufe ich selten auf

[MartinSNippes]

Ich muss php aus den Quellen kompilieren, da ich die Binär-rpm aufgrund einer älteren glibc nicht nutzen kann.


Es sind ALLE Module einkompiliert, die Größe - 60 Megabyte - der Datei (ohne Debug-Information und mit Nutzung von shared libraries) gibt wohl auch vor, dass ALLE Module im Binary stecken...

[tomBuilder]

Ich muss php aus den Quellen kompilieren, da ich die Binär-rpm aufgrund einer älteren glibc nicht nutzen kann.

nutze doch einfach mehre libc's
egal, ich kann nicht auf deine dose und in deinen kopf schaun,du willst nicht deine ini cheken - bin raus.

[MartinSNippes]

Um dieses Thema abzuschließen:
Das Problem mit den "unresolved symbols" ließ sich nicht lösen. Keine Chance, die Pakete selber zu bauen, die auch funktionieren. Nach Durchschauen von anderen Foren scheint dieses Problem schon lange zu bestehen und nun wohl auch noch in der letzten php 7.4 Version.
Da ich SuSE nutze, gibt es dort auch Support für ältere Versionen (long term support) und so konnte ich Pakete einer dieser LTS-Versionen nutzen. Das System läuft wieder und ich werde mir das nächste Mal 3 Mal überlegen, ob ich ein Update mache.
Danke für die Unterstützung!

[tomBuilder]

Das Problem mit den "unresolved symbols" ließ sich nicht lösen. Keine Chance, die Pakete selber zu bauen, die auch funktionieren

compilieren sieht meist sehr einfach auch, ist es auch, soalnge keien probleme auftreten ...
allerdings verstehe ich das mit der cli version nicht ...
wie dem auch sei, danke füer die rückmeldung

[MartinSNippes]

Uj, über ein Jahr ist vergangen, und Software muss aktualisiert werden. Also neuer Versuch, gleiche Probleme, aber diesmal gelöst.
Das Problem bestand in Modulen und binary, mal thread safe, und dann wieder nicht - somit auch die "unresolved symbols".
Problem konnte ich mit der configure Option "--enable-maintainer-zts" lösen. Alle anderen php7 Software pieces habe ich auch neu kompiliert. Nun haut es hin.