wg JSON PHP 5.2. kompilieren - Probleme

[frankx]

Hellihello,

weil die beiden JSON-Funktionen encode und decode erst ab PHP5.2 zur verfügung stehen, wollte ich ich das kompilieren auf meinem virtuellen Server. Ich nehme fürs ./configure die selben Einstellungn, die im Ordner PHP-5.1.6 funktionieren.

Beim 5.2 kommt aber:

  
sed: error while loading shared libraries: libc.so.6: failed to map segment from shared object: Cannot allocate memory  
  
configure: warning: You will need re2c 0.12.0 or later if you want to regenerate PHP parsers.  

ein "make" bricht dann ab:

  
cc1: out of memory allocating 27752400 bytes after a total of 7688192 bytes  
make: *** [ext/date/lib/parse_date.lo] Error 1  

Hätte jemand einen Ansatz?

Dank und Gruß,

frankx

[Christoph Schnauß]

hallo,

sed: error while loading shared libraries: libc.so.6: failed to map segment from shared object: Cannot allocate memory

Ein relativ häufiger Fehler. /lib/libc.so.6 ist in aller Regel ein Systemlink auf die korrekte Bibliotheksdatei, bei mir (Gentoo) auf /lib/libc-2.6.1.so. Du müßtest nachschauen, welche Bibliotheken denn bei dir in /lib herumliegen und dir diesen Systemlink vermutlich neu bauen.

ein "make" bricht dann ab:

Das ist der Folgefehler.

Grüße aus Berlin

Christoph S.

[frankx]

Hellihello Christoph,

bei mir wird in der /lib (Suse 8.5?) angezeigt:

  
1356 -rwxr-xr-x   1 root root 1383801 Jun 11  2005 libc.so.6  

Ich check zwar nicht ganz, woran ein Link zu erkennen ist, denn in der Regel sieht das dann ja so aus:

  
 0 lrwxrwxrwx   1 root root      15 Sep  7  2006 libblkid.so.1 -> libblkid.so.1.0  

(Vorhin bastelte ich aber mal einen selbst mit "link" und der sah dannach nicht so aus (kein Pfeil, kein "l" an erster Stelle der Rechtevergabe, war aber wohl auch einer.)

Immherin ist die Datei im /lib/libc.so.6 wohl kein Link, dafür ist si e ja zu groß. Was mich wundert ist, dass PHP 5.1.6 diese Datei scheinbar nicht braucht, während 5.2.4 hier Problemen hat.

Grüße auch aus Berlin

frankx

[Christoph Schnauß]

hallo,

bei mir wird in der /lib (Suse 8.5?) angezeigt:

Wirklich SUSE 8.5?

1356 -rwxr-xr-x   1 root root 1383801 Jun 11  2005 libc.so.6

Sehr eigentümlich. Bei mir kommt (SUSE 10.2) mit
   ls -l /lib |grep libc.so
als Ergebnis:
   lrwxrwxrwx  1 root root    11 Dec 19 2006 libc.so.6 -> libc-2.5.so

Es hat einen Grund, weshalb das "normalerweise" ein Systemlink ist. Und zum Teil siehst du den an deinen Fehlermeldungen. Diese Bibliothek(en) werden von der glibc benötigt, ohne die der gcc nun einmal nicht gerne arbeiten möchte. Du könntest einmal nachschauen, welche gcc-Version du hast.
Bei älteren SUSEs kann es auch mal an binutils hängen.

Und auch den Hinweis von Sven auf den Speicherbedarf solltest du zu berücksichtigen versuchen.

Grüße aus Berlin

Christoph S.

[frankx]

Hellihello Christoph,

Wirklich SUSE 8.5?

uname verrät mir das ja nicht. Was muss ich sagen?

1356 -rwxr-xr-x   1 root root 1383801 Jun 11  2005 libc.so.6

Sehr eigentümlich. Bei mir kommt (SUSE 10.2) mit
   ls -l /lib |grep libc.so
als Ergebnis:
   lrwxrwxrwx  1 root root    11 Dec 19 2006 libc.so.6 -> libc-2.5.so

Da kommt bei mir auch das o.g. raus.

Es hat einen Grund, weshalb das "normalerweise" ein Systemlink ist. Und zum Teil siehst du den an deinen Fehlermeldungen. Diese Bibliothek(en) werden von der glibc benötigt, ohne die der gcc nun einmal nicht gerne arbeiten möchte. Du könntest einmal nachschauen, welche gcc-Version du hast.

Naja, wie gesagt, jetzt klappt das mit dem configure ja. Vermutung dann doch, dass 5.2.4 mehr Systemresourcen braucht als auf einem Strato-Virtuozzo-Plesk-Suse8.5-Server zur Verfügung steht?

Grüße aus Südwest-Berlin

frankx

[frankx]

Hellihello

jetzt habe ich das ./configure nochmal laufen lassen, nachdem ich drei Sachen rausgenommen hatte, die er angemahnt hatte:

Notice: Following unknown configure options were used:

--with-_lib=lib
--enable-memory-limit
--enable-gd-native-ttfcd

(die hatte ich bei 5.1.6 auch drin, den hatten sie nicht gestört).

Nun schien mir, als liefe er durch:

Generating files
updating cache ./config.cache
creating ./config.status
creating php5.spec
creating main/build-defs.h
creating scripts/phpize
creating scripts/man1/phpize.1
creating scripts/php-config
creating scripts/man1/php-config.1
creating main/php_config.h
creating main/internal_functions.c
creating main/internal_functions_cli.c
+--------------------------------------------------------------------+
| License:                                                           |
| This software is subject to the PHP License, available in this     |
| distribution in the file LICENSE.  By continuing this installation |
| process, you are bound by the terms of this license agreement.     |
| If you do not agree with the terms of this license, you must abort |
| the installation process at this point.                            |
+--------------------------------------------------------------------+

Thank you for using PHP.

Dennoch, die Probleme beim "make" bleiben aber...???

h1028341:/robert/php-5.2.4 # make
/bin/sh /robert/php-5.2.4/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/date/lib -Iext/date/ -I/robert/php-5.2.4/ext/date/ -DPHP_ATOM_INC -I/robert/php-5.2.4/include -I/robert/php-5.2.4/main -I/robert/php-5.2.4 -I/usr/include/libxml2 -I/robert/php-5.2.4/ext/date/lib -I/robert/php-5.2.4/ext/mbstring/oniguruma -I/robert/php-5.2.4/ext/mbstring/libmbfl -I/robert/php-5.2.4/ext/mbstring/libmbfl/mbfl -I/usr/include/mysql -I/robert/php-5.2.4/TSRM -I/robert/php-5.2.4/Zend    -I/usr/include -g -O2  -prefer-non-pic -c /robert/php-5.2.4/ext/date/lib/parse_date.c -o ext/date/lib/parse_date.lo

cc1: out of memory allocating 64674804 bytes after a total of 3317760 bytes
make: *** [ext/date/lib/parse_date.lo] Error 1

Dank und Gruß,

frankx

[Sven Rautenberg]

Moin!

cc1: out of memory allocating 64674804 bytes after a total of 3317760 bytes
make: *** [ext/date/lib/parse_date.lo] Error 1

Tja, die Meldung sagt dir, dass das Kompilieren etwa 64 MB Speicher haben wollte, was scheiterte.

Was sagen denn die technischen Daten deines VServers? Und warum kompilierst du PHP 5.2 selbst, gibts da kein Paket deiner Distro?

Und warum nimmst du nicht ersatzweise eine der diversen JSON-Funktionen, die existieren? JSON ist doch nun wirklich keine Geheimwissenschaft, das könnte man ja zur Not noch mühelos selbst programmieren.

- Sven Rautenberg

[frankx]

Hellihello Sven,

Tja, die Meldung sagt dir, dass das Kompilieren etwa 64 MB Speicher haben wollte, was scheiterte.

Danke, das bestätigt einen bisher dumpfen Verdacht.

Was sagen denn die technischen Daten deines VServers? Und warum kompilierst du PHP 5.2 selbst, gibts da kein Paket deiner Distro?

Ach Suse 8.5 mit PLESK als viruteller Server.

Und warum nimmst du nicht ersatzweise eine der diversen JSON-Funktionen, die existieren? JSON ist doch nun wirklich keine Geheimwissenschaft, das könnte man ja zur Not noch mühelos selbst programmieren.

Gut, dass Du das sagst. Ich war jetzt soweit, ohne PECL bzw. direkt das json zu kompilieren (http://aurore.net/projects/php-json/). Fehlt nur der Eintrag in der /etc/php.ini glaub ich. Aber irgendwo dachte ich auch schon das, was Du sagst: selbst eine Klasse bauen.

Dank und Gruß,

frankx

[frankx]

Hellihello,

jetzt wollte ich doch mal wissen, wie sich so eine extension einbauen lässt. Die json.so hatte ich gemäß  http://aurore.net/projects/php-json/ configured, gemaked und make-installed. json.so findet sich nun in  /usr/lib/php/extensions. Jetzt ist aber scheints nicht die /etc/php.ini die entscheidende sondern laut phpinfo() die /etc/php5/php.ini. Setze ich da den Testweise den safe_mode auf "off" dann sehe ich das danach auch in der phpinfo(). Dort (/etc/php5/php.ini) habe ich nun auch das extension_dir eingestellt auf "/usr/lib/php/extensions" und in der php.ini extension=json.so gesetzt. /etc/init.d/apache2 restart - aber nix json-Funktion (json_encode()). Komisch auch, dass die ganzen anderen extensions, die im /usr/lib/php/extensions vorhanden sind, nur in /etc/php.ini aufgeführt sind, aber die spielt ja scheints garkeine Rolle. In der /etc/php5/php.ini steht nur:

include_path=".:/usr/share/php"
output_buffering=On
extension_dir = /usr/lib/php/extensions
extension=json.so
;safe_mode=off

Eigentlich könnten die anderen extensions also garnicht eingebunden sein.

Kann mir jemand einen "hint" geben? (;-).

Dank und Gruß,

frankx

[Christoph Schnauß]

hallo,

Jetzt ist aber scheints nicht die /etc/php.ini die entscheidende sondern laut phpinfo() die /etc/php5/php.ini.
Kann mir jemand einen "hint" geben? (;-).

Probieren wirs mal: gib deiner /etc/php.ini einen anderen Namen oder verschiebe sie in ein temporäres Verzeichnis (wer weiß, vielleicht brauchst du irgendeine Einstellung nochmal und möchtest sie nachlesen). Danach legst du in /etc ganz einfach einen Systemlink auf /etc/php5/php.ini an, den du wieder php.ini nennst.

Die Sache mit den Systemlinks ist in Linux-Kisten schon was Feines.

Grüße aus Berlin

Christoph S.

[frankx]

Hellihello Christoph,

Probieren wirs mal: gib deiner /etc/php.ini einen anderen Namen oder verschiebe sie in ein temporäres Verzeichnis (wer weiß, vielleicht brauchst du irgendeine Einstellung nochmal und möchtest sie nachlesen). Danach legst du in /etc ganz einfach einen Systemlink auf /etc/php5/php.ini an, den du wieder php.ini nennst.

Die Sache mit den Systemlinks ist in Linux-Kisten schon was Feines.

tatich jetzt:

-rw-r--r--  2 root root 128 Sep 27 21:58 php.ini

ist mit ln php5/php.ini php.ini eingerichtet. Warum da kein "l" an erster Stelle steht und nicht so ein schöner Pfeil (->php5/php.ini) versteh ich immer noch nicht, macht aber nischt, denn mit cat php.ini wir dann der Inhalt von php5/php.ini angezeigt.

Nach /etc/initi.d/apache2 restart bleibt die Funktion json_encode() aber unbekannt (das Skript läuft bei mir auf dem Rechner, seitdem ich hier auf 5.2.4 geupdatet hatte).

Und in der php5/php.ini steht nach wie vor:

include_path=".:/usr/share/php"
output_buffering=On

extension_dir = /usr/lib/php/extensions

extension=json.so
;safe_mode=off

stell ich den safe_mode auf on, wird das auch in der phpinfo() so angezeigt.

Komisch ist doch, das in /usr/lib/php/extensions massig *.so drinne stehen:

.          calendar.so  dbx.so      ftp.so      iconv.so  mbstring.so  mime_magic.so  shmop.so    sysvsem.so   xslt.so
..         ctype.so     domxml.so   gd.so       imap.so   mcal.so      mysql.so       snmp.so     sysvshm.so   yp.so
bcmath.so  curl.so      exif.so     gettext.so  json.so   mcrypt.so    pgsql.so       sockets.so  unixODBC.so  zlib.so
bz2.so     dbase.so     filepro.so  gmp.so      ldap.so   mhash.so     session.so     swf.so      wddx.so

darunter mittlerweile auch "meine" json.so. Aber scheinbar werden die ja alle garnicht eingebgunden, oder wie könnte ich das testen? Welche Funktion hängt denn von calender.so oder sonsteiner ab, die ich aufrufen könnte um damit zu schauen, ob diese extension wirklich eingebunden ist. Ah ich sehe die gd.so und, aber mit Datum September 2005, obwohl ich php erst letzlich -with gd-lib (oder so ähnlich) kompiliert hatte.

Dank und Gruß,

frankx

[Harlequin]

Yerf!

Die Sache mit den Systemlinks ist in Linux-Kisten schon was Feines.

tatich jetzt:

-rw-r--r--  2 root root 128 Sep 27 21:58 php.ini

ist mit ln php5/php.ini php.ini eingerichtet. Warum da kein "l" an erster Stelle steht und nicht so ein schöner Pfeil (->php5/php.ini) versteh ich immer noch nicht, macht aber nischt, denn mit cat php.ini wir dann der Inhalt von php5/php.ini angezeigt.

Das liegt daran, dass du den Parameter "-S" beim ln vergessen hast.

Hintergrund: es gibt 2 Arten von Links, Symbolic und Hard

Die mit den Pfeilen im Verzeichnis sind Symbolic Links, sie zeigen auf einen anderen Dateinamen.
Die Hard Links zeigen direkt auf eine Datei auf der Platte, sind also im Prinzip ein 2. Eintrag im Dateisystem für die selbe datei (daher auch die 2 im Dateilisting, dass ist die Anzahl der Hard Links auf eine Datei).

Der große Unterschied ergibt sich, wenn man die Ursprungsdatei umbenennt oder löscht: der Symbolic Link zeigt dann ins Leere, wärend der Hard Link sich nicht weiter dafür interesiert, da er ja direkt auf den Startsektor der Datei verweist. Wirklich gelöscht ist eine Datei erst, wenn alle Hard Links auf sie gelöscht wurden.

Gruß,

Harlequin

PS: Windows kann seit NTFS (glaub Version 5) ebenfalls Links. Allerdings nur Symbolic Links auf Verzeichnisse und Hard Links auf Dateien. Die anderen 2 Varianten werden nicht unterstützt.

[frankx]

Hellihello Harlequin,

wer ist denn yerf?

Das liegt daran, dass du den Parameter "-S" beim ln vergessen hast.

Die mit den Pfeilen im Verzeichnis sind Symbolic Links, sie zeigen auf einen anderen Dateinamen.

Ah alles klar, die Symbolic-Links sehen also besser aus, sind aber schwächer. Na, so ist das halt im Leben (;-).

Das "l" am Anfang kann ich aber über chmod nicht beeinflussen, oder? Sonst kriegt man die Buchstabenkette damit ja "zu fassen".

Dank und Gruß,

frankx

[Harlequin]

Yerf!

Ah alles klar, die Symbolic-Links sehen also besser aus, sind aber schwächer. Na, so ist das halt im Leben (;-).

Sie sind auch die am meisten benutzten. Liegt wohl auch daran, dass manche Programme eine veränderte Datei speichern, indem sie das Original umbenennen (als Backup) und dann eine neue Datei erzeugen. Jetzt Zeigt der Hard-Link immer noch auf die alte Datei, der Symbolik Link aber auf die geänderte (neue).

Das "l" am Anfang kann ich aber über chmod nicht beeinflussen, oder? Sonst kriegt man die Buchstabenkette damit ja "zu fassen".

Nein. Der erste Buchstabe gibt den Typ des Verzeichniseintrags an. - für Datei, d für Verzeichnis und l für Symbolic Link. Dass es keine Kennzeichnung für Hard Links gibt liegt daran, dass diese sich nicht von "normalen" Dateieinträgen[1] unterscheiden und man bei einer Datei auf die es 2 Links gibt nicht sagen kann: "das eine ist das Original und das andere der Link" Im Prinzip sind beides Originale. (Ein Verschieben von Dateien innerhalb einer Partition basiert auf dem Prinzip: Hard Link an neuer Stelle erzeugen und dann den alten entfernen)

Gruß,

Harlequin

[1] Ein "normaler" Dateieintrag ist der erste Hard Link auf die Datei. Man kann aber beliebig viele weitere Erzeugen.

[frankx]

Hellihello Zusammnen,

cc1: out of memory allocating 64674804 bytes after a total of 3317760 bytes
make: *** [ext/date/lib/parse_date.lo] Error 1

Tja, die Meldung sagt dir, dass das Kompilieren etwa 64 MB Speicher haben wollte, was scheiterte.

Nun habe ich das Ding nochmal versucht zu maken. Vielleicht, weil es sich um einen virtuellen Server handelt, hat es jetzt geklappt, weil aus irgendeinem Grund Speicherplatz frei war (RAM? SWAP?). Das make install (inkl. u.g. Befehle inkl. Fehlermeldungen) war insofern erfolgreich, als phpinfo() nun PHP 5.2.4 anzeigt und json_encode() funktioniert (Wahnsinn, ich weiß... (;-).

Warum die Einbindung der Extension nicht funktioniert hat, bleibt mir ein Rätsel, das mit der jetzigen Konfiguration aber nicht mehr ausgetestet werden kann, gelle?

Sollte hier einer vorbeidödeln, der mir Anhaltspunkte für folgende Medlungen geben könnte, wär ich dankbar, fürs Verständnis:

Don't forget to run 'make test'.

// mach ich also
h1028341:/robert/php-5.2.4 # make test
//ging dann aber nicht, kommt:

Build complete.
Don't forget to run 'make test'.

ERROR: Cannot run tests without CLI sapi.

//nun, also make install:
h1028341:/robert/php-5.2.4 # make install

Installing PHP SAPI module:       apache2handler
/usr/share/apache2/build/instdso.sh SH_LIBTOOL='/usr/share/apache2/build/libtool' libphp5.la /usr/lib/apache2-prefork
/usr/share/apache2/build/libtool --mode=install cp libphp5.la /usr/lib/apache2-prefork/
cp .libs/libphp5.so /usr/lib/apache2-prefork/libphp5.so
cp .libs/libphp5.lai /usr/lib/apache2-prefork/libphp5.la
libtool: install: warning: remember to run `libtool --finish /robert/php-5.2.4/libs'
chmod 755 /usr/lib/apache2-prefork/libphp5.so

// alles gut, aber:
apxs:Error: Activation failed for custom /etc/apache2/httpd2-prefork.conf file..
apxs:Error: At least one `LoadModule' directive already has to exist..
make: *** [install-sapi] Error 1

// dies problem gabs sonst aber auch meine ich, bzw. diese fehlermeldung. scheint aber den apache2 nicht zu jucken, und das php auch nicht.

// weil das oben angesagt war, dann dieses mir rätselhafte libtool --finish etc.

h1028341:/robert/php-5.2.4 # libtool --finish /robert/php-5.2.4/libs
PATH="$PATH:/sbin" ldconfig -n /robert/php-5.2.4/libs
----------------------------------------------------------------------
Libraries have been installed in:
   /robert/php-5.2.4/libs

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the -LLIBDIR' flag during linking and do at least one of the following:    - add LIBDIR to the LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the LD\_RUN\_PATH' environment variable      during linking    - use the -Wl,--rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
h1028341:/robert/php-5.2.4 #

was macht denn das?

Dank und Gruß,

frankx

[Christoph Schnauß]

hallo,

weil aus irgendeinem Grund Speicherplatz frei war (RAM? SWAP?)

Vermutlich SWAP.

Warum die Einbindung der Extension nicht funktioniert hat, bleibt mir ein Rätsel, das mit der jetzigen Konfiguration aber nicht mehr ausgetestet werden kann, gelle?

In der Tat ist das eine von "./configure" und dem gesamten make-Durchlauf völlig unabhängige Gschichte.

Sollte hier einer vorbeidödeln, der mir Anhaltspunkte für folgende Medlungen geben könnte, wär ich dankbar, fürs Verständnis:

h1028341:/robert/php-5.2.4 # make test
//ging dann aber nicht, kommt:
Build complete.
Don't forget to run 'make test'.

Siehe "man make" ;-)

ERROR: Cannot run tests without CLI sapi.

Das ist doof, aber ziemlich eindeutig. Und es betrifft deine ./configure-Einstellungen.

apxs:Error: Activation failed for custom /etc/apache2/httpd2-prefork.conf file.
apxs:Error: At least one `LoadModule' directive already has to exist.

Was steht denn in deiner /etc/apache2/httpd2-prefork.conf drin? Existiert die üeberhaupt?

h1028341:/robert/php-5.2.4 # libtool --finish /robert/php-5.2.4/libs
PATH="$PATH:/sbin" ldconfig -n /robert/php-5.2.4/libs
[...]
h1028341:/robert/php-5.2.4 #
was macht denn das?

Was interessiert dich daran? Du landest doch ohne Fehlermeldung wieder auf der Konsole, sofern du alles richtig gepostet hast

Grüße aus Berlin

Christoph S.

[frankx]

Hellihello Christoph,

besten Dank,

Warum die Einbindung der Extension nicht funktioniert hat, bleibt mir ein Rätsel, das mit der jetzigen Konfiguration aber nicht mehr ausgetestet werden kann, gelle?

In der Tat ist das eine von "./configure" und dem gesamten make-Durchlauf völlig unabhängige Gschichte.

Ja, "aber" wenn jetzt im Bundle json mit drinne ist, kann ich ja schlecht probieren, ob ich die Extension noch installiert kriege (;-), des meinte ich.

Sollte hier einer vorbeidödeln, der mir Anhaltspunkte für folgende Medlungen geben könnte, wär ich dankbar, fürs Verständnis:

h1028341:/robert/php-5.2.4 # make test
//ging dann aber nicht, kommt:
Build complete.
Don't forget to run 'make test'.

Siehe "man make" ;-)

Yes, rtfm.

ERROR: Cannot run tests without CLI sapi.

Das ist doof, aber ziemlich eindeutig. Und es betrifft deine ./configure-Einstellungen.

--disable-cli (ich dachte damit disable ich einen start von php über Konsole, weil ich das eh nicht bräuchte)?

apxs:Error: Activation failed for custom /etc/apache2/httpd2-prefork.conf file.
apxs:Error: At least one `LoadModule' directive already has to exist.

Was steht denn in deiner /etc/apache2/httpd2-prefork.conf drin? Existiert die üeberhaupt?

Ja:

h1028341:/etc/apache2 # ls -ls httpd2-prefork.conf
4 -rw-r--r--  1 root root 66 Sep 27  2006 httpd2-prefork.conf
h1028341:/etc/apache2 # cat httpd2-prefork.conf
LoadModule php4_module /usr/lib/apache2-prefork/libphp4.so

Also eine LoadModule-Directive existiert ja wohl, wenn auchdie auf die php4 Version, die ich nicht will und die z.Z. auch nicht läuft (es läuft ja jetzt 5.2.4.).

h1028341:/robert/php-5.2.4 # libtool --finish /robert/php-5.2.4/libs
PATH="$PATH:/sbin" ldconfig -n /robert/php-5.2.4/libs
[...]
h1028341:/robert/php-5.2.4 #
was macht denn das?

Was interessiert dich daran? Du landest doch ohne Fehlermeldung wieder auf der Konsole, sofern du alles richtig gepostet hast

Du meinst, alles was kein Fehler macht, interessiert mich nicht (;-)?
Es interessierte mich immer mal wieder insofern, als ich bisher dachte, mit ./configure, make, make installe wärst getan. von libtool --finish war da nie die Rede, schon garnicht neuerdings mit der Pfadangabe zu einem .../libs - Direktory. Aber ich lebe auch ganz gut mit der Unwissenheit, solange es "funzt".

Grüße aus einem rotbeholundertem Teil von Berlin
und Dank,

frankx