Hallo, ich möchte gerne mod_php 4.4.0 von Hand installieren. Ich habe ein Suse 9.3 System. Der Apache liess sich ohne Probleme installieren. Bei PHP bekomme ich aber eine Fehlermeldung bei 'make install'. Nachdem ich das Makefile auseinander genommen habe, weiss ich nun, dass es an den compilierten 'php' liegt. Hier die Configure-Zeile für php: ./configure --prefix=/www/php --with-apxs=/www/bin/apxs --with-config-file-path=/www/conf --disable-ipv6 --enable-exif --with-mysql --enable-bcmath --with-gd --with-jpeg-dir --with-png-dir --with-t1lib --with-zlib-dir --with-ttf --with-freetype-dir --enable-track-vars --with-calendar=shared --enable-magic-quotes --enable-wddx --enable-trans-sid --with-mcrypt --with-openssl --with-bison --with-curl --enable-socket --enable-ftp --with-bz2 --with-imap --with-imap-ssl --enable-mbstring --with-xslt-sablot=/usr --with-expat-dir=/usr --with-xmlrpc --enable-xslt --enable-yp --enable-memory-limit --enable-zend-multibyte --with-dom --with-gettext --with-mhash --with-recode --with-mm --enable-sysvmsg --enable-sysvsem --enable-sysvshm --with-pear' Der Apache liegt in /www. Das Compilieren (make) funktioniert ohne Probleme, sobald doch 'make install' aufgerufen wird: make[1]: *** [install-pear-installer] Segmentation fault Wie gesagt, nach einigem Suchen bin ich dann darauf gestossen, dass das Binary von PHP abstürtzt. suse:/tmp/mod_php-4.4.0 # ./sapi/cli/php -v Segmentation fault Hier ein ldd: suse:/tmp/mod_php-4.4.0 # ldd sapi/cli/php linux-gate.so.1 => (0xffffe000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x4001e000) libc-client.so => /usr/lib/libc-client.so (0x40051000) libnsl.so.1 => /lib/libnsl.so.1 (0x40113000) libsablot.so.0 => /usr/lib/libsablot.so.0 (0x40128000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40207000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0x402c5000) libmm.so.13 => /usr/lib/libmm.so.13 (0x402e4000) librecode.so.0 => /usr/lib/librecode.so.0 (0x402e9000) libmhash.so.2 => /usr/lib/libmhash.so.2 (0x40424000) libmcrypt.so.4 => /usr/lib/libmcrypt.so.4 (0x4045a000) libltdl.so.3 => /usr/lib/libltdl.so.3 (0x4048b000) libdl.so.2 => /lib/libdl.so.2 (0x40492000) libpam.so.0 => /lib/libpam.so.0 (0x40496000) libt1.so.1 => /usr/lib/libt1.so.1 (0x4049f000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x404e6000) libpng.so.3 => /usr/lib/libpng.so.3 (0x40555000) libz.so.1 => /lib/libz.so.1 (0x40583000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40594000) libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0x405b3000) libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0x405e4000) libbz2.so.1 => /usr/lib/libbz2.so.1 (0x406d7000) libresolv.so.2 => /lib/libresolv.so.2 (0x406e7000) libm.so.6 => /lib/tls/libm.so.6 (0x406fa000) libcurl.so.3 => /usr/lib/libcurl.so.3 (0x4071d000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0x4074c000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40861000) libc.so.6 => /lib/tls/libc.so.6 (0x40873000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4098c000) /lib/ld-linux.so.2 (0x40000000) Wenn eine Liste von yast2 gebraucht wird, mit der installierten Software, bzw einen strace-dump, den kann ich gerne nachliefern. Der 'make install' läuft auf anderen Systemen (Gentoo, Debian Woody, Debian Sarge) ohne Probleme durch. Daher meine Frage: Was ist hier falsch? Alte Pakete sind auch nicht installiert, es wurde kurz davor ein Online Update durchgeführt. Ich hoffe Ihr könnt helfen. Sonnige Grüsse, Timo Eckert
On Tue, 6 Sep 2005 16:46:44 +0200 Timo Eckert <eckert@ipexmedia.com> wrote: So, nachdem ich nun bestimmt 30 mal PHP compiliert habe, ist der schuldige gefunden. Und zwar handelt es sich um die library "recode", welche entweder in SuSE fehlerhaft ist, oder sich nicht mit PHP 4.4.0 versteht. Ist da was bekannt? Sonnige Grüsse, Timo Eckert
Am Mittwoch, den 07.09.2005, 16:30 +0200 schrieb Timo Eckert:
On Tue, 6 Sep 2005 16:46:44 +0200 Timo Eckert <eckert@ipexmedia.com> wrote:
So,
nachdem ich nun bestimmt 30 mal PHP compiliert habe, ist der schuldige gefunden. Und zwar handelt es sich um die library "recode", welche entweder in SuSE fehlerhaft ist, oder sich nicht mit PHP 4.4.0 versteht.
Ist da was bekannt?
also ich habs unter suse9.3 und apache 1.3.31 zum laufen gebracht mit: --with-recode=shared probier das mal. oder hast du das schon probiert? -- einen schönen Tag noch DI Rainer Klier Abteilung IT - Entwicklung ECOLOG Logistiksysteme GmbH Bauernstraße 11, A-4600 Wels Tel. ++43/7242/66200 Fax ++43/7242/66200-200 mailto:kra@ecolog.at http://www.ecolog.at
Am Mittwoch, den 07.09.2005, 18:44 +0200 schrieb Timo Eckert:
On Wed, 07 Sep 2005 17:53:40 +0200 Rainer Klier <kra@ecolog.at> wrote:
also ich habs unter suse9.3 und apache 1.3.31 zum laufen gebracht mit: --with-recode=shared
Hast Du das recode-php Modul dann auch in der php.ini geladen?
hatte ich bis jetzt vergessen. habs jetzt eingetragen, und es hat funktioniert. allerdings hab ich noch keine recode-funktion ausprobiert. ich hab einfach nur php compilieren und starten können. auch der apache startet mit diesem php. -- einen schönen Tag noch DI Rainer Klier Abteilung IT - Entwicklung ECOLOG Logistiksysteme GmbH Bauernstraße 11, A-4600 Wels Tel. ++43/7242/66200 Fax ++43/7242/66200-200 mailto:kra@ecolog.at http://www.ecolog.at
On Wed, Sep 07, 2005 at 04:30:31PM +0200, Timo Eckert wrote:
On Tue, 6 Sep 2005 16:46:44 +0200 Timo Eckert <eckert@ipexmedia.com> wrote:
So,
nachdem ich nun bestimmt 30 mal PHP compiliert habe, ist der schuldige gefunden. Und zwar handelt es sich um die library "recode", welche entweder in SuSE fehlerhaft ist, oder sich nicht mit PHP 4.4.0 versteht.
Ist da was bekannt?
Ja, da ist was bekannt. php4-recode vertraegt sich wegen sich ueberschneidenden Symbolen nicht mit php4-imap, php4-mysql und apache2-mod_auth_mysql. Peter -- the little machine that goes "ping" imitated the pink can of spam
participants (3)
-
poeml@cmdline.net
-
Rainer Klier
-
Timo Eckert