Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
PHP5 has been released, and the ebuild should be updated. I have successfully emerged PHP5 and will post ebuilds and changes I had to make momentarily. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created an attachment (id=35349) [details] mod_php 5.0.0 ebuild
Created an attachment (id=35350) [details] php-5.0.0 ebuild
Created an attachment (id=35351) [details] php-5.0.0 ebuild
(From update of attachment 35350 [details]) oops
Created an attachment (id=35352) [details] /etc/apache2/conf/modules.d/70_mod_conf.php
I also had to: - put php5_soap_persistence_session.diff in the files path of both ebuilds (using portage overlay) - Add "-gdbm" to my use flags (or add dba) - Add an "IfDefine PHP5" section to 70_mod_conf.php (see attachment) - Remove the package.mask entry for php-5.0.0
I think this is a dupblicate of bug #32563
So where do I get php5_soap_persistence_session.diff from?
/usr/portage/dev-php/mod_php/files/php5_soap_persistence_session.diff It's needed for php-5.0.0-r1 too.
ok, with the new mod_php.conf and -D PHP5 set, mod_php no longer reads /etc/php/apache2-php4/php.ini (as expected, I suppose). But there is no /etc/php/apache2-php5/. And creating one doesn't get php to read it. Where does php5 expect php.ini to be now?
From phpinfo(): Configuration File (php.ini) Path /etc/php/apache2-php5/php.ini I found this in the .sapi file: my_conf="${my_conf} --with-config-file-path=/etc/php/${PHPSAPI}-php5/php.ini" Of course, that path and file don't exist, so it's using the php defaults.
No dice. phpinfo() says: "'./configure' '--prefix=/usr' '--host=i686-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--with-apxs2=/usr/sbin/apxs2' '--with-config-file-path=/etc/php/apache2-php5/php.ini' '--disable-bcmath' '--with-bz2' '--disable-calendar' '--without-cpdflib' '--disable-ctype' '--with-curl' '--with-curlwrappers' '--disable-dbase' '--enable-dbx' '--enable-dio' '--disable-exif' '--without-fam' '--without-fbsql' '--without-fdftk' '--disable-filepro' '--disable-ftp' '--with-gettext' '--without-gmp' '--without-hwapi' '--with-iconv' '--without-informix' '--without-ingres' '--without-interbase' '--enable-mbstring' '--with-mcrypt' '--without-mcve' '--without-mhash' '--without-ming' '--without-mnogosearch' '--without-msql' '--without-mssql' '--with-ncurses' '--without-oci8' '--without-oracle' '--with-openssl' '--without-ovrimos' '--without-pcre-regx' '--without-pfpro' '--without-pgsql' '--disable-posix' '--with-pspell' '--without-recode' '--without-snmp' '--with-soap' '--enable-sockets' '--without-sybase' '--without-sybase-ct' '--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm' '--with-tidy' '--disable-wddx' '--with-xsl' '--with-xmlrpc' '--disable-yp' '--with-zlib' '--without-cdb' '--with-db4' '--without-dbm' '--without-flatfile' '--with-gdbm' '--without-inifile' '--without-ndbm' '--without-qdbm' '--with-gd' '--enable-gd-jis-conf' '--enable-gd-native-ttf' '--with-imap' '--without-kerberos' '--with-imap-ssl' '--with-ldap' '--with-ldap-sasl' '--with-mysql' '--without-mm' '--without-msession' '--enable-sqlite-utf8' '--enable-dba' '--without-readline' '--without-libedit'" And "Configuration File (php.ini) Path /etc/php/apache2-php5/php.ini " Created /etc/php/apache2-php5/php.ini (by copying /etc/php/apache2-php4/php.ini), and restarted Apache. But phpinfo() says: "include_path: .:/usr/lib/php" for both Local and Master, even though /etc/php/apache2-php5/php.ini says "include_path = ".:/usr/lib/php:/htdocs/resources/global-config:/htdocs/resources/config:/htdocs/resources"" Numerous other values are customized in php.ini, but phpinfo() doesn't show them. I'm obviously missing something. Regardless, I think the ebuild should create this php.ini file in the new location. Also, when I had tidy set in my USE flags, compilation would fail. If I emerged tidy, it would work, of course. The ebuild doesn't appear to calculate that as a dependency correctly. I eventually had to have USE="-readline -snmp -odbc" set to compile, for the same reason.
Nice to read that people are trying out the ebuilds :) Earlier in the day, I bumped both php-5.0.0 and mod_php-5.0.0 to use PHP5-final rather than RC3. The missing SOAP patch is no longer missing. I've just finished sorting out most of the dependencies for PHP 5, and the builds now create and install the php.ini file for you. I've also added some additional checks for USE flag combinations that aren't valid. These changes should be appearing on your local rsync mirror in about an hour. Apart from mistakes in the eclass, AFAIK the only things left to sort out are ODBC support (about time I learned about it anyhow) and Kerberos. Please emerge sync, and re-emerge these ebuilds to test. Best regards, Stu
Stu, I have the same problem with your mod_php ebuild. Also, your 70_mod_php5.conf has extramodules/libphp5.so but after emerging your ebuild, libphp5.so is actually in modules, not extramodules.
Hi Miles, Er, please be more specific. There's quite a few problems listed in here :) I'll look at the apache conf file in the morning, and get that sorted out. Best regards, Stu
Sorry, Stu. My problem is that php is clearly compiled to use /etc/php/apache2-php5/php.ini as the php.ini location. However, directives I put in that file (like include_path), don't take effect. phpinfo() shows this.
Miles, Okay, that was *probably* caused by a bug in the eclass, and should have been fixed along with last night's work. If you emerge sync, rebuild php 5, it should work for you. Best regards, Stu
*** Bug 57101 has been marked as a duplicate of this bug. ***
please note this from php 5 ./configure help: "--with-config-file-path=PATH" description: "Sets the path in which to look for php.ini, defaults to PREFIX/lib" this is the PATH, meaning the **folder** where php.ini is found. So instead of PATH=/etc/php/apache2-php5/php.ini, it needs to be PATH=/etc/php/apache2-php5/ if you want to use that directory. -Noah
Yup, and that's what it was changed to yesterday :) Please - and this is a general request, not just for bugs about our PHP 5 support: don't post or comment on a bug unless you're sure you have the latest ebuilds and eclasses. Saves everyone lots of time and trouble, and helps us provide a better service to you. Many thanks, Stu
Sorry. I did an emerge sync right after your comment at 15:11 PST, and sure enough, the php5 ebuilds showed up in the tree. So I deleted the ebuilds I downloaded from this bug, and emerged the new ones. Not much else I can do to make sure I have the latest ebuilds and eclasses. I'll re-sync, re-build, and let you know how it goes. Thanks.
Hi Myles, It takes about an hour for changes made to CVS to reach the rsync mirrors; sometimes longer if the mirrors are having a bad day. It seems that you emerge sync'd before the hour was up. Best regards, Stu
Everyone who's having problems getting mod_php5 to run ... which version of Apache are you using? The stuff in Portage works fine for me w/ Apache 2 ... I've committed a new config file which hopefully will fix things for Apache 1 users. Let me know how you get on please. Thanks Stu
Stu-- I have another question concerning jpeg (with gd) support... I had looked through the forums and searched bugzilla but didn't find anything on the topic. In php 4.*, there was a 'jpeg' USE flag to enable/disable this feature. In the php5 ebuilds, this use flag is not there according to `emerge -pv /usr/portage/dev-php/php/php-5.0.0.ebuild`. Thoughts on this? I need jpeg support, so is this another bug that should be opened? Thanks, Noah
*** Bug 32563 has been marked as a duplicate of this bug. ***
i made some changes in my ebuild: --- php5-sapi.eclass.bak 2004-07-20 19:08:56.703470432 +0200 +++ php5-sapi.eclass 2004-07-20 20:09:55.480251816 +0200 @@ -25,3 +25,3 @@ S="${WORKDIR}/${MY_P}" -IUSE="${IUSE} adabas bcmath birdstep bzlib calendar cpdflib crypt ctype curl curlwrappers db2 dbase dbmaker dbx dio esoob exif fam frontbase fdftk filepro ftp gmp hyperwave-api iconv informix ingres interbase iodbc libedit mcve mhash ming mnogosearch msession msql mssql mysql ncurses nls nis oci8 oracle7 ssl ovrimos pcre pfpro postgres posix readline recode sapdb session shared simplexml snmp soap sockets solid spell spl ssl sybase sybase-ct sysvipc tidy tokenizer truetype odbc wddx xsl xml2 xmlrpc zlib dba cdb berkdb flatfile gdbm inifile qdbm empress empress-bcs gd gd-external imap kerberos ssl ldap sasl pcntl sqlite" +IUSE="${IUSE} adabas bcmath birdstep bzlib calendar cpdflib crypt ctype curl curlwrappers db2 dbase dbmaker dbx dio esoob exif fam frontbase fdftk filepro ftp gmp hyperwave-api iconv informix ingres interbase iodbc libedit mcve memlimit mhash ming mnogosearch msession msql mssql mysql ncurses nls nis oci8 oracle7 ssl ovrimos pcre pfpro postgres posix readline recode sapdb session shared simplexml snmp soap sockets solid spell spl ssl sybase sybase-ct sysvipc tidy tokenizer truetype odbc wddx xsl xml2 xmlrpc zlib dba cdb berkdb flatfile gdbm inifile qdbm empress empress-bcs gd gd-external imap kerberos ssl ldap sasl pcntl sqlite" @@ -39,3 +39,2 @@ gmp? ( dev-libs/gmp ) - iconv? ( dev-libs/libiconv ) imap? ( virtual/imapd ) @@ -160,7 +159,2 @@ - case "$PHPSAPI" in - cli|cgi) - enable_extension_with "pcntl" "pcntl" 1 ;; - esac - confutils_use_conflict "readline" "libedit" @@ -300,2 +294,3 @@ enable_extension_with "mcve" "mcve" 1 + enable_extension_enable "memory-limit" "memlimit" 0 enable_extension_with "mhash" "mhash" 1 @@ -311,2 +306,3 @@ enable_extension_without "pcre-regx" "pcre" 1 + enable_extension_enable "pcntl" "pcntl" 1 enable_extension_with "pfpro" "pfpro" 1 pcntl: 1. enable_extension_with -> enable_extension_enable 2. i know that pcntl shouldn't be enabled within a webserver environment, but emerging mod_php also builds the cli version and i need pcntl to be enabled in that. it might be reasonable to force --disable-cli in the mod_php ebuild and make users emerge php for the cli. this method would result in two independent php.ini files for the apache modul and the cli - it sounds good to me... but it wouldn't be comfortable. see also this bugreport: http://bugs.gentoo.org/show_bug.cgi?id=22735 iconv: from the php manual: "You will need nothing if the system you are using is one of the recent POSIX-compliant systems because standard C libraries that are supplied in them must provide iconv facility." http://bugs.gentoo.org/show_bug.cgi?id=57244 just my two cents
ftl, Thanks for that feedback. I've just committed an updated php5-sapi.eclass, which should be appearing on your local rsync mirror in about an hour. Best regards, Stu
>>QUOTE ------- Additional Comment #24 From Noah Pritikin 2004-07-17 14:13 PST ------- I have another question concerning jpeg (with gd) support... I had looked through the forums and searched bugzilla but didn't find anything on the topic. In php 4.*, there was a 'jpeg' USE flag to enable/disable this feature. In the php5 ebuilds, this use flag is not there according to `emerge -pv /usr/portage/dev-php/php/php-5.0.0.ebuild`. Thoughts on this? I need jpeg support, so is this another bug that should be opened? Thanks, Noah <<QUOTE I had the same "problem" that my app uses GD with JPEG support. Indeed I didn't find any Use flag either. I solved it by hacking the .ebuild from: my_conf="${my_conf} --with-apxs${USE_APACHE2}=/usr/sbin/apxs${USE_APACHE2}" to: my_conf="${my_conf} --with-jpeg-dir=/usr --with-apxs${USE_APACHE2}=/usr/sbin/apxs${USE_APACHE2}"
jpeg is fixed in cvs. I've added the packages for mcve and cpdflib into the portage tree, and updated the eclass(es) appropriately. QDBM was already in the portage tree, so I've just put the nessicary depends into the eclass. Fixed IMAP-SSL build. Added Oracle sanity check. Filepro support. Major INI file work: - sets extension_dir - secures allow_url_fopen if SAPI != cli - sets include_path - sets up all possible extension= entries (for shared support) I would also appreciate everybody trying the updated eclass. If no problems are reported in the next week, I'm aiming on releasing PHP5 into ~arch.
it's in ~x86 now :-)
