Erstellt vor 6 Jahren

Geschlossen vor 6 Jahren

Zuletzt geändert vor 5 Jahren

#1753 closed version bump (fixed)

PHP version bump to 5.4.0

Erstellt von: Suchiman Verantwortlicher: er13
Priorität: normal Meilenstein: freetz-2.0
Komponente: packages Version: devel
Stichworte: Beobachter:
Product Id: Firmware Version:

Beschreibung

Anbei ein Patch um PHP auf 5.4.0 zu bumpen. Scheint bei mir zu Funktionieren. Größe des Binarys ist von 5.2M auf 4.6M geschrumpft mit allen Erweiterungen ausgewählt. Signifikante änderung: GD lib von system weit auf "Bundled" geändert, da die PHP entwickler irgendetwas geändert haben sodass mit externer GD Lib einige compile Fehler entstehen, scheint ein bekanntes Problem zu sein. Ob in der php.mk "$(PKG)_DEPENDS_ON += gd" weiterhin erforderlich ist weiß ich nicht. GD funktioniert aber weiterhin (getestet). Außerdem scheint die Geschwindigkeit erheblich besser zu sein. Kommentar von PHP seite: "PHP 5.4.0 significantly improves performance, memory footprint and fixes over 100 bugs."

Anhänge (6)

php_5_4_0.patch (4.2 KB) - hinzugefügt von Suchiman vor 6 Jahren.
config.carstenschuette.txt (36.6 KB) - hinzugefügt von CarstenSchuette vor 6 Jahren.
php54new.patch (6.1 KB) - hinzugefügt von Suchiman vor 6 Jahren.
v2
php-version-bump-5.4.1RC2.patch (5.5 KB) - hinzugefügt von er13 vor 6 Jahren.
php.ini (3.1 KB) - hinzugefügt von Suchiman vor 6 Jahren.
Entsprechend http://www.php.net/manual/de/ini.list.php angepasst
php_to_5.4.2.patch (1.4 KB) - hinzugefügt von MaxMuster vor 6 Jahren.

Alle Anhänge herunterladen als: .zip

Änderungshistorie (39)

Geändert vor 6 Jahren durch Suchiman

comment:1 Antwort: Geändert vor 6 Jahren durch Suchiman

Die php.ini sollte eventuell auch noch überarbeitet werden, zwar funktioniert sie mit Default werten, aber einige Einträge scheinen inzwischen überflüssig zu sein: "Removed: Safe mode and all related ini options."

Zuletzt geändert vor 6 Jahren von Suchiman (vorher) (Diff)

comment:2 Antwort: Geändert vor 6 Jahren durch CarstenSchuette

Sagt bei mir, dass er png.h nicht finden könnte, obwohl die benötigten Libs im Image enthalten sind.

comment:3 als Antwort auf: ↑ 2 Geändert vor 6 Jahren durch Suchiman

Replying to CarstenSchuette:

Sagt bei mir, dass er png.h nicht finden könnte

Hast du vorher im PHP Verzeichniss aufgeräumt ? make php-dirclean oder gar einen neuen Checkout ? Ich hatte einen neuen Checkout gemacht, meinen Patch eingespielt, PHP mit allen Features aktiviert und dieses Image nutze ich aktuell.

comment:4 Geändert vor 6 Jahren durch CarstenSchuette

Ja, "make php-dirclean", dann Patch über "patch -p0 -i <patchfile>" eingespielt, anschließend "make menuconfig", php 5.4.0 ausgewählt, dann "make". Der lädt was runter, wendet ein paar Patches an, und der configure-Teil endet dann mit:

checking whether libxml build works... 
checking for ENCHANT support... no
checking whether to enable EXIF (metadata from images) support... yes
checking for fileinfo support... no
checking whether to enable input filter support... yes
checking pcre install prefix... no
checking whether to enable FTP support... no
checking OpenSSL dir for FTP... no
checking for GD support... yes
checking for the location of libvpx... no
checking for the location of libjpeg... no
checking for the location of libpng... no
checking for the location of libXpm... no
checking for FreeType 2... no
checking for T1lib support... no
checking whether to enable truetype string function in GD... yes
checking whether to enable JIS-mapped Japanese font support in GD... no
checking for fabsf... yes
checking for floorf... yes
If configure fails try --with-jpeg-dir=<DIR>
If configure fails try --with-vpx-dir=<DIR>
configure: error: png.h not found.

ERROR: Build failed.
make: *** [source/target-mips_uClibc-0.9.32.1/php-5.4.0/.configured] Error 1

linjpeg und libpng sind aber beide bei mir ausgewählt (als external). php 5.3.10 läuft auch prima durch, aber 5.4.0 eben nicht. Config folgt.

Zuletzt geändert vor 6 Jahren von CarstenSchuette (vorher) (Diff)

Geändert vor 6 Jahren durch CarstenSchuette

comment:5 Geändert vor 6 Jahren durch Suchiman

Ich weiß jetzt grad nicht woran es genau liegt, aber hast du alle Packete von Freetz installiert? http://freetz.org/wiki/help/howtos/common/install#InstallationderbenötigtenPaketeUbuntu

comment:6 Geändert vor 6 Jahren durch CarstenSchuette

Ja, habe ich - libpng etc. dürfen beim Bauen doch gar nicht vom Hostsystem genommen werden, sondern müssten aus dem Toolchain kommen. Sonst wird doch gegen eventuell völlig falsche Versionen gebaut, oder sehe ich das falsch?

comment:7 Geändert vor 6 Jahren durch MaxMuster

Carsten hat recht, die Host-Includes wären "böse".
Das ganze dürfte an der Änderung für "GD" liegen, was jetzt "intern" genutzt wird, denn dafür scheint png genutzt zu werden.

Bei mir hat ein beherztes $(PKG)_CONFIGURE_OPTIONS += --with-png-dir="$(TARGET_TOOLCHAIN_STAGING_DIR)/usr" Wunder gewirkt ;-).

Vermutlich müssten/sollten aber die GD-Abhängigkeiten hier noch auftauchen, bevor man die Abhängigkeit von gd selbst rausnimmt…

comment:8 Geändert vor 6 Jahren durch cuma

  • Meilenstein auf freetz-1.3 gesetzt

comment:9 Geändert vor 6 Jahren durch Suchiman

Ich habe den Patch überarbeitet, für den neuesten Trunk und unter berücksichtigung folgenden Links
http://www.php.net/manual/de/image.installation.php
Aus der Config.in die abhängigkeit zu libgd entfernt und für PNG und JPEG hinzugefügt. Außerdem den nicht mehr enthaltenden safe mode aus den Standardeinstellungen entfernt

WARNUNG: Im laufenden noch nicht getestet. Kompilieren (sollte) es aber

Zuletzt geändert vor 6 Jahren von Suchiman (vorher) (Diff)

Geändert vor 6 Jahren durch Suchiman

v2

comment:10 Geändert vor 6 Jahren durch er13

In 8915:

libgd:

  • bump version to 2.0.36RC1 (contains fixes of libgd bundled with recent php versions)
  • refs #1753

comment:11 Antwort: Geändert vor 6 Jahren durch er13

  • Status von new nach assigned geändert
  • Verantwortlicher auf er13 gesetzt

@Suchiman: könntest Du bitte Deinen Patch überarbeiten, sodass weiterhin die freetz' libgd verwendet wird und nicht die bundled. Danke!

Edit: und warum löschst Du den 500-ttyname_r.patch?

Zuletzt geändert vor 6 Jahren von er13 (vorher) (Diff)

comment:12 Geändert vor 6 Jahren durch Suchiman

Kann ich machen, auch wenn ich nicht weiß ob das so viel besser ist. Laut der PHP Webseite ist das Bundled deutlich Optimierter und unterstützt auch Features die die originale libgd nicht beinhaltet wie Alpha Blending.

http://www.php.net/manual/de/image.requirements.php

Hinweis:  Seit PHP 4.3 ist eine Version der GD-Bibliothek in PHP enthalten. Diese gebündelte Version bietet zusätzliche Möglichkeiten, wie z.B. alpha blending und sollte der externen Version immer vorgezogen werden (der Code wird besser betreut und ist stabiler).

comment:13 Geändert vor 6 Jahren durch er13

Alpha-Blending wird seit 2.0.2 unterstützt. Die restlichen Fixes habe ich in r8915 eingecheckt.

comment:14 als Antwort auf: ↑ 11 ; Antwort: Geändert vor 6 Jahren durch Suchiman

Replying to er13:

Edit: und warum löschst Du den 500-ttyname_r.patch?

Weil er sich nicht mehr Anwenden lies und das Programm ohne diesen Patch sowohl kompilierte als auch auf der Box Läuft

EDIT: http://suchiman.selfip.org/phpinfo.php

Zuletzt geändert vor 6 Jahren von Suchiman (vorher) (Diff)

comment:15 als Antwort auf: ↑ 14 ; Antworten: Geändert vor 6 Jahren durch er13

Replying to Suchiman:

Weil er sich nicht mehr Anwenden lies und das Programm ohne diesen Patch sowohl kompilierte als auch auf der Box Läuft

Läuft in deiner Konfiguration… Die Warning über thread-unsafe hast Du gelesen?

comment:16 als Antwort auf: ↑ 15 Geändert vor 6 Jahren durch Suchiman

Replying to er13:

Läuft in deiner Konfiguration… Die Warning über thread-unsafe hast Du gelesen?

Oh… Okay ich werd mich nochmal dransetzen und schauen

comment:17 Antwort: Geändert vor 6 Jahren durch er13

Mache erstmal nichts. Es ist doch nicht so einfach wie ich erwartet habe. Ich schaue es mir an, wenn ich etwas Zeit habe.

comment:18 als Antwort auf: ↑ 17 Geändert vor 6 Jahren durch Suchiman

Replying to er13:

Mache erstmal nichts. Es ist doch nicht so einfach wie ich erwartet habe. Ich schaue es mir an, wenn ich etwas Zeit habe.

Okay, danke

comment:19 Geändert vor 6 Jahren durch er13

Geändert vor 6 Jahren durch er13

comment:20 als Antwort auf: ↑ 1 Geändert vor 6 Jahren durch er13

Replying to Suchiman:

Die php.ini sollte eventuell auch noch überarbeitet werden, zwar funktioniert sie mit Default werten, aber einige Einträge scheinen inzwischen überflüssig zu sein: "Removed: Safe mode and all related ini options."

Würdest Du bitte das Anpassen der php.ini übernehmen, Danke!

Geändert vor 6 Jahren durch Suchiman

comment:21 Geändert vor 6 Jahren durch er13

  • Lösung auf fixed gesetzt
  • Status von assigned nach closed geändert

In 8943:

php:

comment:22 Geändert vor 6 Jahren durch er13

In 8944:

target-tester:

  • add ac_cv_func_fnmatch_works required by php
  • refs #1753

comment:23 Geändert vor 6 Jahren durch CarstenSchuette

PHP 5.4 verhält sich an vielen Stellen doch anders als PHP 5.3, ich habe einige Programme gesehen, die nicht mit 5.4 laufen. Daher finde ich diesen Version Bump heute nicht mehr so gut, besser wäre es, beide PHP-Versionen anzubieten.

comment:24 Geändert vor 6 Jahren durch er13

In 8953:

php:

  • fix build problems with libxml-support enabled
  • refs #1753
  • fixes #1795

comment:25 als Antwort auf: ↑ 15 Geändert vor 6 Jahren durch Suchiman

Replying to er13:

Läuft in deiner Konfiguration… Die Warning über thread-unsafe hast Du gelesen?

Ich habe mich bezüglich der Thread-Safety weil du es hier angesprochen hattest jetzt informiert. Ich weiß jetzt nicht ob Apache überhaupt mod_php verwendet, aber wenn PHP für den Einsatz als CGI / FastCGI kompiliert wird, sollte Thread-Safety deaktiviert werden. Grund dafür ist, denn PHP bietet auch non / Thread-safe Binarys an, dass die Thread-Safety nur für den Multithreaded Einsatz als Apache Modul benötigt wird und andernfalls bei CGI / FastCGI benutzung auf die eh schon kostbare Performance schlägt wegen der hierbei notwendigen Thread Synchronisation.

Quellen:

http://www.iis-aid.com/articles/my_word/difference_between_php_thread_safe_and_non_thread_safe_binaries

[…] The performance increase is not to be sneezed at either as I've seen figures of upto 40% mentioned […]

http://technet.microsoft.com/en-us/library/dd239230(v=ws.10).aspx

It is recommended that you use a non-thread-safe build of PHP with IIS 7 FastCGI. A non-thread-safe build of PHP provides significant performance gains over the standard build by not doing any thread-safety checks. These checks are not necessary because FastCGI guarantees a single-threaded execution environment.

Deshalb sollte man Thread-Safety entweder nur aktivieren wenn Apache ausgewählt ist, oder deaktivieren wenn lighttpd, bzw. ein Server ausgewählt ist der PHP über CGI / FastCGI nutzt.

Zuletzt geändert vor 6 Jahren von Suchiman (vorher) (Diff)

comment:26 Geändert vor 6 Jahren durch CarstenSchuette

Man sollte aus meiner Sicht eine Option dafür haben, ob man thread-safe oder thread-unsafe bauen will. Ich glaube nicht, dass man das über die config automatisch ermitteln kann. Nur an Stellen, an denen man definitiv weiß, dass thread-safe benötigt wird (apache), könnte diese Option automatisch aktiviert werden.

Wenn man sich übrigens über Performance unterhält, dann sollte man auch mal einen Blick auf http://php.net/manual/de/book.apc.php bzw. http://pecl.php.net/package/apc werfen.

Zuletzt geändert vor 6 Jahren von CarstenSchuette (vorher) (Diff)

comment:27 Antwort: Geändert vor 6 Jahren durch cinereous

Es gibt da noch diverse andere Caching-Mechanismen. Da nur auf einen gucken wäre wenig hilfreich.

comment:28 als Antwort auf: ↑ 27 Geändert vor 6 Jahren durch CarstenSchuette

Richtig, aber APC ist aus unserer Erfahrung für Produktivsysteme der am Besten geeignetste. Ob das auf einer FritzBox auch so ist, kann ich nicht beurteilen. Eigentlich ging es hier ja auch gerade um thread-safety.

comment:29 Geändert vor 6 Jahren durch MaxMuster

Hier eine Patch auf 5.4.2.
Um es statisch zu bauen, musste ich den "alten" Patch (700-remove_libgd_function.patch) wieder einführen (der in [8943] gelöscht wurde).
Ist das ein Problem nur bei mir?!?

Geändert vor 6 Jahren durch MaxMuster

comment:30 Geändert vor 6 Jahren durch er13

In 8982:

php:

  • bump version to 5.4.2
  • fix php doesn't compile if FREETZ_PACKAGE_PHP_STATIC is selected
  • by MaxMuster
  • refs #1753

comment:31 Geändert vor 6 Jahren durch er13

In 8996:

php:

  • bump version to 5.4.3 (contains fix for CVE-2012-1823)
  • refs #1753

comment:32 Geändert vor 5 Jahren durch er13

In 9366:

php:

  • readd php-5.3.x support because of compatibility issues
  • refs #1753

comment:33 Geändert vor 5 Jahren durch cuma

  • Meilenstein von freetz-1.3 nach freetz-2.0 geändert
Hinweis: Hilfe zur Verwendung von Tickets finden Sie in TracTickets.