php-5.3.3-r1 compiles, installs and runs just fine on ~x64-macos. Changes to the original files: * prefix inheritance added to the ebuild * eblits have been eprefixified by hand as ecopy failed because of the eblit path in 'files/', so they might contain some errors/mistakes. * Two patches in ${FILESDIR} where eprefixified with @GENTOO_PORTAGE_EPREFIX@ (20php5-envd, php-fpm.init) * Some configure paths have been added (eg iconv, gettext) * iconv extension inclusion was changed from 'without' to 'with' as building used to fail. (And was 'with' in php5_2-sapi.eclass…) Included upstream patches: * http://bugs.php.net/bug.php?id=52413 > php-5.3.3-ulong-osx.patch Tested USE-Flags: apache2 bzip2 calendar cgi cli crypt ctype curl curlwrappers exif fileinfo filter ftp gd hash iconv json mysql mysqli nls pdo phar posix readline session simplexml soap sockets sqlite3 ssl tokenizer truetype unicode xml xmlreader xmlrpc xmlwriter xsl zip zlib Kudos to heiko_ from #gentoo-prefix.
Created attachment 248000 [details] Complete dev-lang/php directory I hope you don't mind that format, but it's easier than adding >10 files... ;)
Created attachment 248001 [details] Ebuild changes Diff of the original ebuild VS eprefix ebuild.
Created attachment 248003 [details] Eblits changes Contains the changes made to the eblits files as diff. Maybe someone could look over those and find some mistakes…
Created attachment 248120 [details] Complete dev-lang/php directory Changes: * Moved the ulong-osx.patch from the src_prepare-v1.eblit eblit to ebuilds' src_prepare() (thx heiko) * Added "${EPREFIX}/usr" to sharedmem extensions in src_configure-v1.eblit * Fixed a double prefix error in line 30 src_install-v1.eblit * builds on ~x86-macos! ;) * New tested (and working) USE-flags: gd-external pcntl sharedext sharedmem
thanks, committed your work
reopening for some more fixes
Created attachment 248638 [details] correctly installs shared extensions Shared extensions got built but not installed on OS X. The hardcoded .so ending was changed to $(get_modname) where applicable. kudos to heiko_ and ABCD from #gentoo-prefix
Created attachment 248639 [details] adds proper ${EPREFIX}/usr paths to some use flags With this configure the following use flags compile and install properly: gmp, spell, cdb, berkdb, gdbm, qdbm, imap
Created attachment 248642 [details, diff] Patch to src_configure-v1.eblit that was needed on my box to make it compile These modification were necessary to compile PHP over here. My USE flags are: cat ${EPREFIX}/var/db/pkg/dev-lang/php-5.3.3-r1/USE apache2 bzip2 cli crypt ctype curl elibc_Darwin exif fileinfo filter ftp gd gdbm gmp hash iconv ipv6 json kernel_Darwin mysql pcntl pdo phar posix postgres prefix readline session sharedext sharedmem simplexml soap sockets spell ssl sysvipc tokenizer truetype unicode userland_GNU x86 x86-macos xml xmlreader xmlrpc xmlwriter zlib Bug 195765 addressed the same issue for php-5.2. Maybe some prefixes can be taken from there. BTW: for pgsql I fed it the directory to pg_config as this should make it more portable.
Created attachment 248644 [details] adds proper ${EPREFIX}/usr paths to some use flags (In reply to comment #9) > Created an attachment (id=248642) [details] > Patch to src_configure-v1.eblit that was needed on my box to make it compile Thx, added. > Bug 195765 addressed the same issue for php-5.2. Maybe some prefixes can be > taken from there. All paths changes from the php5_2-sapi.eclass are already in the eblit. > BTW: for pgsql I fed it the directory to pg_config as this should make it more > portable. Don't know about that one, but I didn't change it so... ;) Thx!
(In reply to comment #7) (In reply to comment #10) Committed, thx.
ok, heiko says this is not working, so heiko do your thing
(In reply to comment #12) > ok, heiko says this is not working, so heiko do your thing > Sorry to shake the holy happy php world once more, but there are still issues. When trying dev-lang/php-5.3.3 on ~amd64-linux the configure script errored out pretty early: checking whether to enable LIBXML support... yes checking libxml2 install dir... no checking for xml2-config path... configure: error: xml2-config not found. Please check your libxml2 installation. Interestingly I do have ${EPREFIX}/usr/bin/xml2-config, since libxml2 is a dep due to my USE: amd64 berkdb bzip2 cli crypt ctype elibc_glibc fileinfo filter gdbm hash iconv ipv6 json kernel_linux mysql mysqli phar posix prefix readline session simplexml ssl tokenizer unicode userland_GNU xml xmlreader xmlwriter zlib After looking at things there're two problems coming together: a) configure invoking 'for i in $PHP_LIBXML_DIR /usr/local /usr; do' b) src-configure-v1.eblit issuing 'phpconfutils_extension_disable "libxml" "xml" 0' So php's configure just looks in predefined paths plus the one given in --with-libxml=LIBXML_DIR. And the eblit defines how to react on the xml flag (by disabling the per default enabled libxml support). Unfortunately, that phpconfutils_extension_disable call doesn't allow for addition of "${EPREFIX}"/usr at the end like the enable versions do, without changing the eclass (and even if changing the eclass would be done, phpconfutils_extension_disable would need to return --with-libxml=..., which doesn't match the functions actual --enable/--disable purpose). Using phpconfutils_extension_with[out] doesn't work either, since there's only --disable-libxml and no --without-libxml in php's configure. phpconfutils_extension_enable doesn't allow for providing --with-libxml. That problem will probably be the case for other extensions as well. I'm not quite sure how to handle the problem, except for introducing a new function phpconfutils_extension_with_or_disable or patching configure. Or maybe I'm just missing something and there's no problem at all? For the other testers: You probably had luck with USE=xml, since your host has /usr/bin/xml2-config. The "cool" nature of prefix then makes the compiler and linker look in ${EPREFIX}/usr first, thus your binaries link against the correct libxml2 but were probably incorrectly configured.
Created attachment 249468 [details, diff] Patch to address heikos issue (In reply to comment #13) > (In reply to comment #12) > > ok, heiko says this is not working, so heiko do your thing > > > > I'm not quite sure how to handle the problem, except for introducing a new > function phpconfutils_extension_with_or_disable or patching configure. Or maybe > I'm just missing something and there's no problem at all? While wondering why it didn't raise any issue on my system with similar effects I discovered I had xml2-config in /usr/bin. Nevertheless, otool revealed php was linked against libxml in $EPREFIX. Here comes my bet at fixing the issue. It uses standard ebuild methods to pass the proper options to configure. I noticed in attachment 160956 [details, diff] that for PHP4.2 expat-dir was used, but I have my doubts whether this would work in the case where "xml" USE flag is not enabled.
Created attachment 249469 [details, diff] Patch to turn libphp5.so to libphp5.bundle While we're at it, here comes a patch to turn libphp5.so into libphp5.bundle. It came around as a side work of fixing something that someone before and faster then me ultimately had fixed already. It requires two more files to be put in $FILESDIR that I will attach separately.
Created attachment 249471 [details, diff] File in ${FILESDIR} required to make attachment 249469 [details, diff] work correctly.
Created attachment 249473 [details, diff] File in ${FILESDIR} required to make attachment 249469 [details, diff] work correctly.
(In reply to comment #14) > Created an attachment (id=249468) [details] > Patch to address heikos issue > > (In reply to comment #13) > > (In reply to comment #12) > > > ok, heiko says this is not working, so heiko do your thing > > > > > > > I'm not quite sure how to handle the problem, except for introducing a new > > function phpconfutils_extension_with_or_disable or patching configure. Or maybe > > I'm just missing something and there's no problem at all? > > While wondering why it didn't raise any issue on my system with similar effects > I discovered I had xml2-config in /usr/bin. Nevertheless, otool revealed php > was linked against libxml in $EPREFIX. > Meh, I was too slow this time. ;) Nevertheless, my original post: (In reply to comment #13) > (In reply to comment #12) > > ok, heiko says this is not working, so heiko do your thing > > > > Sorry to shake the holy happy php world once more, but there are still issues. <snip> > I'm not quite sure how to handle the problem, except for introducing a new > function phpconfutils_extension_with_or_disable or patching configure. Or maybe > I'm just missing something and there's no problem at all? > What about just adding this to the eblit: if use xml ; then my_conf="${my_conf} --with-libxml-dir=${EPREFIX}/usr" fi With all the DEPEND and RDEPEND for different extensions depending on libxml it all comes down to the xml use flag. By adding that line all is well: --- (changed username to "me" to protect the innocent) 480 checking whether to enable LIBXML support... yes 481 checking libxml2 install dir... /Users/me/Gentoo/usr 482 checking for xml2-config path... /Users/me/Gentoo/usr/bin/xml2-config 483 checking whether libxml build works... yes <snip> 526 checking for xml2-config path... (cached) /Users/me/Gentoo/usr/bin/xml2-config 527 checking whether libxml build works... (cached) yes <snip> 662 checking for xml2-config path... (cached) /Users/me/Gentoo/usr/bin/xml2-config 663 checking whether libxml build works... (cached) yes <snip> 723 checking for xml2-config path... (cached) /Users/me/Gentoo/usr/bin/xml2-config 724 checking whether libxml build works... (cached) yes --- I don't know if gentoo maintainers could live with that. Basically it would only add some redundancy and that causes no harm. ;)
(In reply to comment #15) > Created an attachment (id=249469) [details] > Patch to turn libphp5.so to libphp5.bundle > > While we're at it, here comes a patch to turn libphp5.so into libphp5.bundle. > > It came around as a side work of fixing something that someone before and > faster then me ultimately had fixed already. It requires two more files to be > put in $FILESDIR that I will attach separately. > Cool, thx a lot! I get the following "error", although the module finds its way to the correct dir nevertheless: --- make -j3 INSTALL_ROOT=/Users/me/Gentoo/var/tmp/portage/dev-lang/php-5.3.3-r1/work/sapis/apache2/ install-sapi Installing PHP SAPI module: apache2handler /Users/me/Gentoo/usr/lib/apache2/build/instdso.sh SH_LIBTOOL='/Users/me/Gentoo/usr/bin/glibtool' libs/libphp5.bundle /Users/me/Gentoo/var/tmp/portage/dev-lang/php-5.3.3-r1/work/sapis/apache2//Users/me/Gentoo/usr/lib/apache2/modules /Users/me/Gentoo/usr/bin/glibtool --mode=install cp libs/libphp5.bundle /Users/me/Gentoo/var/tmp/portage/dev-lang/php-5.3.3-r1/work/sapis/apache2//Users/me/Gentoo/usr/lib/apache2/modules/ glibtool: install: cp libs/libphp5.bundle /Users/me/Gentoo/var/tmp/portage/dev-lang/php-5.3.3-r1/work/sapis/apache2//Users/me/Gentoo/usr/lib/apache2/modules/libphp5.bundle Warning! dlname not found in /Users/me/Gentoo/var/tmp/portage/dev-lang/php-5.3.3-r1/work/sapis/apache2//Users/me/Gentoo/usr/lib/apache2/modules/libphp5.bundle. Assuming installing a .so rather than a libtool archive. chmod 755 /Users/me/Gentoo/var/tmp/portage/dev-lang/php-5.3.3-r1/work/sapis/apache2//Users/me/Gentoo/usr/lib/apache2/modules/libphp5.so chmod: Zugriff auf „/Users/me/Gentoo/var/tmp/portage/dev-lang/php-5.3.3-r1/work/sapis/apache2//Users/me/Gentoo/usr/lib/apache2/modules/libphp5.so“ nicht möglich: No such file or directory apxs:Error: Command failed with rc=65536 --- Any ideas?
(In reply to comment #19) > Any ideas? php built a .so and a .bundle. However, it would ignore the .bundle and install the .so. The patch makes the .bundle be used whenever .so was, so the .bundle get installed (try `find image -name '*.bundle'`). Unless I forgot a modification I did to my system that makes it different than the others in this regard, the installation nevertheless continued successfully and a `emerge php` would get the php installed on my system properly. When I get some time I'll dig into php again to get the error message fixed. If for some reason my patch broke your system I'll do it earlier. ;)
(In reply to comment #18) > What about just adding this to the eblit: > if use xml ; then > my_conf="${my_conf} --with-libxml-dir=${EPREFIX}/usr" > fi > > With all the DEPEND and RDEPEND for different extensions depending on libxml it > [...] > I don't know if gentoo maintainers could live with that. Basically it would > only add some redundancy and that causes no harm. ;) > Well I didn't like that approach, since it avoids using phpconfutils splits the logic for that one extension into several pieces, so I just found that the openssl way would be nice: phpconfutils_extension_disable "libxml" "xml" 0 + phpconfutils_extension_with "libxml-dir" "xml" 0 "${EPREFIX}/usr" ;) I found additional problems with the extenstions bz2, curl, iconv, xsl, zlib. Also I wonder why readline/libedit weren't offset'ed. I'll attach a patch.
Created attachment 249649 [details, diff] Some essential offsets. Probably still more needed. Since I kinda lost overview this patch is based on rsync as of 'Mon Oct 4 20:10:51 UTC 2010' (timestamp content). Maybe we should just add the offset to phpconfutils_extension_with and phpconfutils_extension_enable calls and wait for things to break (like with the iconv offset).
Additionally USE=fpm is broken, since the patch doesn't apply: * Failed Patch: php-fpm-gentooified.patch ! * ( /Gentoo/usr/portage/dev-lang/php/files/php-fpm-gentooified.patch patching file sapi/fpm/php-fpm.conf Hunk #1 FAILED at 8. Hunk #2 FAILED at 17. Hunk #4 FAILED at 213. 3 out of 4 hunks FAILED -- saving rejects to file sapi/fpm/php-fpm.conf.rej Actually I start to wonder what is not broken with php :)
(In reply to comment #23) > Additionally USE=fpm is broken, since the patch doesn't apply: > Ok, there's bug #331735 which has been fixed in gx86. Probably a sync from gx86 would be nice then.
(In reply to comment #21) > (In reply to comment #18) > > What about just adding this to the eblit: > > if use xml ; then > > my_conf="${my_conf} --with-libxml-dir=${EPREFIX}/usr" > > fi [...] > Well I didn't like that approach, since it avoids using phpconfutils splits the > logic for that one extension into several pieces, so I just found that the > openssl way would be nice: > phpconfutils_extension_disable "libxml" "xml" 0 > + phpconfutils_extension_with "libxml-dir" "xml" 0 > "${EPREFIX}/usr" There is already logic that does not use the phpconfutils in the src_configure eblit. I just tested your approach with USE "apache2 bzip2 cli crypt ctype curl elibc_Darwin exif fileinfo filter ftp gd gdbm gmp hash iconv ipv6 json kernel_Darwin mysql pcntl pdo phar posix postgres prefix readline session sharedext sharedmem sockets spell ssl sysvipc tokenizer truetype unicode userland_GNU x86 x86-macos zlib" (copied from the ebuild output) and the configure script did not complain. --without-libxml-dir got emitted as part of the configure parameters, however.
confused about state of this bug. summary doesn't make sense, no updates for awhile. closing, please open NEW bugs.
(In reply to comment #26) > confused about state of this bug. summary doesn't make sense, no updates for > awhile. closing, please open NEW bugs. The bug was abort version-bumping PHP in Gentoo-prefix. At least that's what I made of it.
