From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 Description of problem: PHP 5 has been released and has many advantages over PHP 4. It would be nice if rpm's could be created for PHP 5. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Not applicable 2. 3. Additional info:
Created attachment 102404 [details] new spec file for php5 this is a php spec file i've used for compiling php5. it's no where near perfect, but it does include an interbase option, and the minimal patch references necessary to get the thing going. it only uses the install patch that already comes with the source rpm for php4.3.3 and higher, and also it uses a libtool patch which has been posted on php-dev and was supplied to me by joe orton (thanks joe), but i'll re-post it here as a separate attachment if it is helpful to someone it doesn't* include the mbstring patch so since i didn't need 16-bit char support, i've commented out the mbstring part in the ./configure line, but it's easy enough to write the patch in to the spec and supply it. php.conf is also supplied (in next attachment).
Created attachment 102405 [details] php.conf file for php5 this goes with the php.spec file also attached to this bug
Created attachment 102406 [details] libtool patch i'm including this, but actually it's needless if you already have a copy of the 4.3.2 libtool15 patch from an earlier source rpm. i changed the name and the contents to refer to '5.0.0' instead of '4.3.2' before i knew what i was doing.. but at least, for anyone who needs it.. here it is
Created attachment 102407 [details] php-4.3.3-install.patch this is another patch, also from a prev version of php, unchanged for php5.. everyone already has this one as well (though i've not hacked the name change), so it's not "new", either.. but i include it as well for ease for someone who wants at it easily..
Created attachment 102612 [details] updated php5 spec file While your spec file is an excellent start, I think there is some merit to keeping the conventions as similar to the php4 conventions as possible. I applied most of your core changes to my php5 spec file. Some changes in my spec file: - I kept all the php4 patches in play, and wrote some additional patches to fix the broken features. - I've disabled tests by default. Since my testbox is a laptop with 312MB of memory, php5 tests were causing all my other apps to be OOM-killed, but eventually passing them all. They can be activated on the rpmbuild line just like oracle, mssql, and interbase.
Created attachment 102613 [details] updated config patch for 5.0.0 Make config file changes for php5
Created attachment 102614 [details] enable lib64 support lib64 support patch moved from php4
Created attachment 102615 [details] select patch Only remaining relevant case from php4 select patch ported to php5.
Created attachment 102616 [details] get rid of easter egg Nuke the easter egg nonsense, ported from php4 to php5.
Created attachment 102617 [details] don't clobber struct in regex.h struct re_registers is used in regex.h, which is being included indirectly, thus, the mbstring/oniguruma define is clobbering it needlessly. Renaming it to php_re_registers resolves the issue.
Created attachment 102618 [details] missing oniguruma/enc BUILD_DIR the config.m4 is missing the oniguruma/enc BUILD_DIR, this patch adds it.
Created attachment 102619 [details] fix php.ini I'm completely baffled as to why the stock php.ini included in the php5 tarball still refers to /usr/lib/php4. This patch corrects that. (Note: All other patches in my spec file come from the php4 package in rawhide)
Re: last comment, it doesn't, it's patched in by php-4.3.4-config.patch Thanks a lot to both for your work.
OK, I finally got around to integrating this all. php-5.0.1-3 is currently uploading to: http://people.redhat.com/jorton/devel-php5/ there's one issue I spotted: the dom extension is getting built into libphp5.so as well as being installed shared, will fix for next time. Extension modules are moved to /usr/lib/php/modules alongside /usr/lib/php/build to remove the /usr/lib/php and /usr/lib/php4 redundancy. Otherwise, 2.0.51+this seems to serve simple test pages OK. Please put any feedback from these packages here.
In 5.0.1-3 /etc/httpd/conf.d/php.conf refers to php4_module and libphp4.so. perl -pi -e "s/4/5/g;" on Source50 and things work. :)
I can't seem to get the rpm installed. I'm getting a failed dependencies for libcurl.so.3. I checked to see if i have curl installed, and i do have curl and curl-devel 7.11 which is the latest version i am seeing, unless there is a new version out there that hasnt hit red carpet yet. This is on a Fedora Core 2 machine.
Kaj, thanks. I had fixed that when testing but forgot to also commit the change. Paul: you should probably try rebuilding from the source RPM (with the change Kaj gives for php.conf) if you want to try this on FC2.
Could these patches be submitted to upstream php? Ideally FC should add only .spec file. Joe, there's no src rpm at http://people.redhat.com/jorton/devel-php5/ I'd like to test it. Thanks.
Marius, if I see it right, these patches are Fedora specific and won't be accepted by upstream, so Joe already submitted relevant things to upstream in the past.
In FC2, there was a patch to fix a build error with bison 1.875: # bison-1.875-2 seems to produce a broken parser; workaround. mkdir Zend && cp ../Zend/zend_{language,ini}_parser.[ch] Zend After discussion with php and bison author, php folks finally fixed php (first they dismissed the bug). I'd like to see the current src rpm and fill bugs to upstream to include patches, where relevant.
It's better to not deviate from the known-good parser which upstream ship anyway. Regenerating with bison-1.875 still produces test failures since some error messages are different, IIRC. Mostly the other patches either have gone upstream, or will be rejected upstream (for instance, libtool 1.5 support and removal of the easter egg); the -lib64 patch is the big one which I'm preparing to commit soon as it's a maintenance nightmare anyway. -odbc -tests and -db4 are all quick-hacks rather than general solutions, so need more work before going upstream.
Oh, the source RPM came out at: http://people.redhat.com/jorton/ not in the devel-php5 directory for some reason.
This can be an FC4 task.
Is there any need to keep PHP4 if we have PHP5 in FC4? In 6 months (when FC4 comes), people can solve the small incompatibilities, if there are any for them. Having only one php version will be clearer.
Yes, of course, that is the plan.
Joe, could you please enable xsl? --with-xsl Spec already requires libxslt-devel. Also, include pear by default in php.ini: < ;include_path = ".:/php/includes" --- > include_path = ".:/usr/share/pear/" (there are no errors if pear it's not installed) Notes about spec in 5.0.1-3 src rpm: there are some configuration options listed for cgi only, shouldn't all of them be in build() and cgi have only --enable-force-cgi-redirect ? == pushd build-cgi build --enable-force-cgi-redirect \ ... --enable-dom=shared \ --with-dom-xslt=%{_prefix} --with-dom-exslt=%{_prefix} \ --with-xsl \ --with-pgsql=shared \ == I'll test updated src rpm if posted to people.redhat.com. Having php 5.0.2 and pushing it to rawhide after FC3 release would be nice too :) Thanks a lot!
w.r.t. enabling xsl, sure. w.r.t. extensions only enabled for CGI build: yes, that's intentional, those are the shared extensions and so there's no point in building them twice
saw that now in ChangeLog, thanks for explaining. I've got an error when adding --with-xsl, I thought that was the problem: ext/xsl/.libs/xsltprocessor.o(.text+0x185): In function `xsl_ext_function_php': /usr/src/redhat/BUILD/php-5.0.1/ext/xsl/xsltprocessor.c:187: undefined reference to `php_dom_object_get_data' ext/xsl/.libs/xsltprocessor.o(.text+0x5ba):/usr/src/redhat/BUILD/php-5.0.1/ext/xsl/xsltprocessor.c:212: undefined reference to `php_dom_create_object' ext/xsl/.libs/xsltprocessor.o(.text+0x6c8):/usr/src/redhat/BUILD/php-5.0.1/ext/xsl/xsltprocessor.c:275: undefined reference to `dom_object_get_node' ext/xsl/.libs/xsltprocessor.o(.text+0xe8a): In function `zif_xsl_xsltprocessor_transform_to_doc': /usr/src/redhat/BUILD/php-5.0.1/ext/xsl/xsltprocessor.c:483: undefined reference to `php_dom_create_object' collect2: ld returned 1 exit status make: *** [sapi/cgi/php] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.19584 (%build) I downloaded php 5.0.2 and built just with ./configure --with-xsl --with-apxs2=/usr/sbin/apxs --with-pgsql --with-mysql --with-config-file-path=/etc and xsl works this way (no dom options specified, unlike rpm spec). ./configure --help | grep dom lists only an option to disable dom, I wonder why the spec explicit specifies dom. Also saw this: - put dom extension in php-dom subpackage again - remove domxml references, replaced with dom now built-in Why isn't dom built in default php module and it's added as extension?
Hmmm, because that adds ~120K to both libphp5.so and /usr/bin/php. Using --with-xsl=shared might work but that depends on module load order. Could you file new RFEs for these extra features? 5.0.2 is now in Raw Hide.