apache-php3-mysql

[Jens Apel]

Hallo *,
Fuer alle, die mich noch nicht kennen, ich habe in Ilmenau
Informatik studiert und arbeite seit einem Jahr bei SmartRing in Erfurt.
Mein erste Linux war SuSE 5.3 mit dem ich damals ein
Interface zu einer Rockwell PCMCIA Karte schrieb, mit der man ueber 
GPS seine Koordinaten bestimmen konnte.

Uwe Scholz wrote:
> Nun zu meinem Problem. Ich habe auf meinem gateway-Rechner zu Hause
> (P90, 32MB, noch SuSE5.3(libc5)- ich weiss ist nicht mehr ganz frisch)
> apache_1.3.9 neu compiliert- funktioniert problemlos. Anschliessend
> mod_perl mittels apxs hinzugefuegt, auch kein Problem. MySQL-3.22.27
> installiert, auch das geht noch.
> Probleme gibt es erst beim uebersetzen von PHP3_3.0.12-mit-MySQL als
> apache-DSO mittels apxs. 

Wie sind denn die settings mit denen PHP-3 configuriert wurde ?

Das Modul wird noch uebersetzt, aber wenn
> apache es laden will "can't resolve sysmbol __base64" und noch ein
> weiters Symbol -- Abbruch. Diese Symbole werden, meiner laienhaften
> Meinung nach, von MySQL "importiert".

base64 ist eine Konvertierung, mit der binaere Daten in "lesbare"
Zeichen umgewandelt werden. Das kann zum Beispiel verwendet werden, 
um .zip Dateien als attachment an eine e-mail anzuhaengen.

Wenn man wissen moechte, wo dieses Symbol drinsteckt, kann man zum
Beispiel 
folgendes tun:

cd /usr/lib
find . -name "*.a" -exec  \; 2>&1 | grep base64
./libresolv.a:base64.o:00000000 r Base64
./libresolv.a:base64.o:00000041 r Pad64
./libresolv.a:base64.o:00000000 T __b64_ntop
./libresolv.a:base64.o:00000250 T __b64_pton
./libresolv.a:base64.o:         U __ctype_b
./libresolv.a:base64.o:         U abort
./libresolv.a:base64.o:         U strchr
./librecode.a:outer.o:         U module_base64
./librecode.a:utf7.o:         U base64_char_to_value
./librecode.a:utf7.o:         U base64_value_to_char
./librecode.a:base64.o:         U _IO_getc
./librecode.a:base64.o:         U _IO_putc
./librecode.a:base64.o:00000040 D base64_char_to_value
./librecode.a:base64.o:00000000 D base64_value_to_char
./librecode.a:base64.o:         U declare_alias
./librecode.a:base64.o:         U declare_single
./librecode.a:base64.o:00000aa0 T module_base64
./librecode.a:base64.o:         U put_byte_helper
./librecode.a:base64.o:00000490 t transform_base64_data
./librecode.a:base64.o:00000000 t transform_data_base64         

Zur Erlaeuterung:
wir suchen (rekursiv) unter /usr/lib nach allel *.a Dateien.
Wenn wir eine gefunden haben fuehren wir das kommando
nm -o {} aus, wobei die {} durch die aktuelle Datei ersetzt werden
nm ist ein Programm, das aus einer Bibliothek alle Symbole anzeigt und
durch -o
ausserdem noch libname und object name ausgibt.
anschliessend werden die Fehlermeldunden mit 2>&1 mit nach stdout
umgeleitet und das
ganze nach base64 gegrept. 
Das gleiche geht natuerlich auch mit den shared object dateien (.so)

So einfach ist Unix... ;-)
 
> habe andere Methoden der Einbindung in Apache getestet -- DSO ueber
> apaci bzw. direkt eincompilieren -- der gleiche Fehler, nur schon beim
> compilieren. Dann bin ich einen Schritt zurueck zu MySQL_3.21.33 --
> gleicher Fehler nur andere Symbole werden angemeckert.
> Jetzt ist eine Neuinstallation meines Gateways faellig, mit fertigen
> RPM`s.

> Mich interessiert aber trotzdem, wo das Problem eigentlich liegt. Kann
> mir jemand helfen ?????

Moegliche Fehlerquellen --> Fehlersuche:
1. *duck* Installverzeichnis ist falsch
2. Gibt es wirklich keine Fehler waehrend der Kompilierung ? Auch keine
Warnung ?
3. Sagt apxs noch irgendwas ?
4. Fehlen vielleicht die Quellen fuer ein PHP-Modul ? (Brauct man
irgendwelche 
MIME quellen ???(weiss ich auch nicht)) 
5. Wurde ldconfig gestartet ? Das erneuert den Cache fuer die Symbole,
die in
dynamischen Bibliotheken so rumliegen.  

Hoffe das motiviert zur Fehlersuche. ;-)

Gruss Jens