PHP/ODBC Verbindung zu Progress Datenbank – pgoe1022.so file not found

Bei manchen Problemen sucht man sich einen Ast!

Ein frisch aufgesetzter Server mit kopierter Progress Installation von einem alten Server kann die Verbindung zum Datenbankserver nicht herstellen.
Folgende Fehlermeldung erscheint:

Warning: odbc_connect(): SQL error: [unixODBC][Driver Manager]Can’t open lib ‚/usr/dlc10/odbc/lib/pgoe1022.so‘ : file not found, SQL state 01000 in SQLConnect in /var/www/dbtest.php on line 26

Der Aufruf von „ldd /usr/dlc10/odbc/lib/pgoe1022.so“ zeigt uns welche Libraries die Datei benötigt:

linux-gate.so.1 => (0xb78b3000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb767d000)
libpgicu22.so => /srv/proalpha/dlc10/odbc/lib/libpgicu22.so (0xb6c29000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb6c24000)
libstdc++-libc6.2-2.so.3 => not found
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb6bfe000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb6ab9000)
/lib/ld-linux.so.2 (0xb78b4000)
libstdc++-libc6.2-2.so.3 => not found

Und siehe da die letzte fehlt tatsächlich! Steckt in dem Paket libstdc++2.10-glibc2.2_2.95.4-24_i386.deb welches ich aus einer älteren ubuntu Version (dapper) kopiert und installiert habe. Anschließend funktioniert der Zugriff problemlos wie auf dem alten Server.

Jetzt bleibt nur noch die kleine Frage; funktioniert das auch mit 64-Bit?!

Wie es aussieht leider nicht – bei gleicher Vorgehensweise bringt „ldd “ folgende Meldung:

linux-gate.so.1 => (0xf7f86000)
libpthread.so.0 => /lib32/libpthread.so.0 (0xf7d4a000)
libpgicu22.so => /srv/proalpha/dlc10/odbc/lib/libpgicu22.so (0xf72f6000)
libdl.so.2 => /lib32/libdl.so.2 (0xf72f1000)
libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0xf72a9000)
libm.so.6 => /lib32/libm.so.6 (0xf7283000)
libc.so.6 => /lib32/libc.so.6 (0xf7120000)
/lib/ld-linux.so.2 (0xf7f87000)

Also aus meiner Sicht eigentlich alles in Ordnung – allerdings kommt beim Starten dann wieder die Fehlermeldung dass die pgoe1022.so nicht gefunden wird.

Wenn man auf einem funktionierenden 32-Bit System (Ubuntu 9.10 oder 8.04) und auf einem mit 64-Bit (Ubuntu 9.04) den Aufruf von „isql -v padbodbc“ verfolgt, dann fällt folgendes auf…

Auf dem nicht funktionierenden 64-Bit System:

mprotect(0x7fd81af07000, 4096, PROT_READ) = 0
futex(0x7fd81b9470ec, FUTEX_WAKE_PRIVATE, 2147483647) = 0
open(„/srv/proalpha/dlc10/odbc/lib/pgoe1022.so“, O_RDONLY) = 3
read(3, „177ELF1113313402335004 „…, 832) = 832
close(3) = 0
brk(0x1086000) = 0x1086000

Und anschließend wird die Fehlermeldung ausgegeben.
Auf dem 32-Bit System sieht der gleiche Aufruf wie folgt aus:

futex(0xb764a06c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
open(„/srv/proalpha/dlc10/odbc/lib/pgoe1022.so“, O_RDONLY) = 3
read(3, „177ELF1113313402335004“…, 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=2574172, …}) = 0
mmap2(NULL, 2173816, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb72bf000
mmap2(0xb74a8000, 167936, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e8) = 0xb74a8000
mmap2(0xb74d1000, 2936, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb74d1000
mprotect(0xb78c3000, 3840, PROT_READ|PROT_WRITE) = 0
mprotect(0xb78c3000, 3840, PROT_READ) = 0
mprotect(0xbfcd9000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = 0
close(3) = 0
open(„/etc/ld.so.cache“, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=31109, …}) = 0
mmap2(NULL, 31109, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb72b7000
close(3) = 0
access(„/etc/ld.so.nohwcap“, F_OK) = -1 ENOENT (No such file or directory)
open(„/srv/proalpha/dlc10/odbc/lib/libpgicu22.so“, O_RDONLY) = 3
read(3, „177ELF111331 T3004“…, 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=11087208, …}) = 0
mmap2(NULL, 10828652, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6863000
mmap2(0xb72a2000, 86016, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xa3e) = 0xb72a2000
close(3) = 0
access(„/etc/ld.so.nohwcap“, F_OK) = -1 ENOENT (No such file or directory)
open(„/usr/lib/libstdc++-libc6.2-2.so.3“, O_RDONLY) = 3
read(3, „177ELF1113312402321004“…, 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=1292301, …}) = 0
mmap2(NULL, 294664, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb681b000
mmap2(0xb6854000, 53248, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x38) = 0xb6854000
mmap2(0xb6861000, 7944, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6861000
close(3) = 0

Und anschließend wird die Verbindung aufgebaut.

So wie ich das sehe wird beide Male die pgoe1022.so verwendet und das 64-Bit System liefert irgendwas retour das nicht passt, im Moment habe ich allerdings nicht die nötige Ruhe um dem Problem weiter auf den Grund zu gehen – bin aber jedem dankbar der mir einen Tip geben kann! 🙂