Can't LoadModule php4_module in den apache 2.0.39 win32
Robman
- webserver
Hallo Freunde !
Ich bin vor kurzem vom Vorgänger Apache 1.3.26 (win32) auf den neuen Server Apache 2.0.39 umgestiegen und hab festgestellt das sich in der httpd.conf einiges verändert hat. Hier eine kurze Zusammenfassung.
Wichtig zum Laden des php4 Modules in v1.3 war:
Das Problem in v2.0 liegt daran, das es keine "ClearModuleList" mehr gibt und daraus resultierend der Fehler beim Laden erscheint:
"Cannot load C:/php4/sapi/php4apache.dll into server: Ein der für die Ausführung
dieser Anwendung notwendige Bibliothekdateien kann nicht gefunden werden."
Ich denke das es im Zusammenhang mit der "ClearModuleList" steht aber ich bin auf kein Ergebniss gekommen. Und Online Doku`s hab ich bisher auch nicht über dieses Phänomen gefunden. Bin für jede Art von Hilfe dankbar. Entweder per Mail oder auf meiner Homepage im GBook.
PS: Bin aus Verzweiflung schon auf OmniHttpd umgestiegen. ;)
Morgen.
Also, ich hab im Moment den 2.0.36er, sowie PHP 4.2.1 und die scheinen sich zu mögen. Im Apache 2.0.39 funktioniert PHP dann wieder nicht.
Naja, also ich würde dir empfehlen, dass du dir den Apache 2.0.36 (ftp://ftp.epix.net/pub/apache/dist/httpd/binaries/win32/.old/), sowie PHP 4.2.1 (http://www.php.net/downloads.php) besorgst und das ganze so einbindest:
LoadModule php4_module C:/PHP/sapi/php4apache2.dll
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps
Gruß
Norbert
hi,
Also, ich hab im Moment den 2.0.36er, sowie PHP 4.2.1 und die scheinen sich zu mögen. Im Apache 2.0.39 funktioniert PHP dann wieder nicht.
Bei mir läuft Apache 2.0.39 mit PHP4.2.1 völlig problemlos
LoadModule php4_module C:/PHP/sapi/php4apache2.dll
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps
Den Script-Alias für das Verzeichnis, in dem die php.exe liegt, und entsprechend -Action application/x-httpd-php "/php/php.exe"- halte ich durchaus ebenfalls für sinnvoll ;-)
Grüße aus Berlin
Christoph S.
Hallo,
- LoadModule php4_module C:/php4/php4apache.dll
- ClearModuleList
AddModule mod_php4.c- ScriptAlias /php/ "C:/php4/"
- AddType application/x-httpd-php .php .php3 .php4 usw.
- Action application/x-httpd-php "/php4/php.exe"
Letzere Anweisung verstehe ich nicht so ganz. Wieso lädst Du erst das Modul und benutzt dann den CGI-Handler? Folgendes müsste reichen:
LoadModule php4_module C:/php4/php4apache2.dll
ClearModuleList
...
AddModule mod_php4.c
AddType application/x-httpd-php .php .php3 .php4 usw.
(oder halt für die CGI-Variante)
ScriptAlias /php/ "C:/php4/"
AddType application/x-httpd-php .php .php3 .php4 usw.
Action application/x-httpd-php "/php4/php.exe"
aber beides macht wenig sinn.
"Cannot load C:/php4/sapi/php4apache.dll into server: Ein der für die Ausführung
dieser Anwendung notwendige Bibliothekdateien kann nicht gefunden werden."
Du musst auch das Apache2.0-Modul von PHP4 einbinden (die Datei heißt php4apache2.dll und nicht php4apache.dll - die 2 nicht vergessen) Gibts aber AFAIK nur ab PHP 4.2.
Grüße,
Christian
Hi,
Ich bin vor kurzem vom Vorgänger Apache 1.3.26 (win32) auf den
neuen Server Apache 2.0.39 umgestiegen
sehr früh und sehr mutig.
Wichtig zum Laden des php4 Modules in v1.3 war:
- LoadModule php4_module C:/php4/php4apache.dll
- ClearModuleList
was soll das bringen? Erst lädst Du einen Modul, und danach zerstörst
Du die Liste aller geladenen Module wieder?
AddModule mod_php4.c
- AddType application/x-httpd-php .php .php3 .php4 usw.
Aha, das kann ich so halbwegs verstehen.
- ScriptAlias /php/ "C:/php4/"
- Action application/x-httpd-php "/php4/php.exe"
Das wiederum nicht. Wenn Du PHP als Modul verwenden willst, brauchst
Du keine CGI-Variante davon, und für diese dann auch wiederum nicht
die Definition eines eigenen CGI-Verzeichnisses.
Das Problem in v2.0 liegt daran, das es keine "ClearModuleList"
mehr gibt und daraus resultierend der Fehler beim Laden erscheint:
Zwischen beiden Beobachtungen besteht kein ursächlicher Zusammenhang.
Ich denke das es im Zusammenhang mit der "ClearModuleList" steht
Ich nicht.
PS: Bin aus Verzweiflung schon auf OmniHttpd umgestiegen. ;)
Ganz schlechte Idee. Was spricht denn dagegen, bei Apache 1.3 zu
bleiben, bis die Apache-Group eine Version 2.x heraus bringt, bei
der sich die APIs mal _nicht_ schneller ändern, als die 3rd-party-
Anbieter ihre Module daraufhin anpassen können?
Viele Grüße
Michael