Patch split from bug 81163. To reiterate, whilst php installs it's files in the correct libdir it currently looks for dependancy libs only in prefix/lib and so fails to compile in our no-symlinks profile.
Created attachment 61742 [details, diff] php5-sapi.eclass multilib fix
I'm working on a patch for php4 now. I'll keep you posted.
Thanks for splitting this out. Adding this patch is on my todo list. Best regards, Stu
Hi, This has been fixed (for both PHP4 and PHP5) in the PHP overlay, but not tested, as I don't have Gentoo/AMD64 installed anywhere. Please make sure you get revision 77 or later from subversion to test against. http://svn.gnqs.org/projects/gentoo-php-overlay/ Best regards, Stu
Umm, stupid question. Where are the fixes? The configure scripts (well, mostly the config.m4 in the extensions) is still looking in /usr/lib/. The configure process (for dev-lang/php-4.4.0) comes as far as this: checking for db4 major version... configure: error: Header contains different ve rsion This comes from ext/dba/config.m4
To avoid confusion: The stuff to put the files into the right location (for multilib-strict) works really fine. The thing that I'm talking about it that compilatin fails when */lib and */lib64 aren't the same directory (symlinked), like in the in-development 2005.1/no-symlinks profile. I just looked, others are patching around to fix the lookups. Redhat for example (which seems to have borrowed the patches from SuSE in turn). I've put the patchset here in case you want to take a look or use the patches. I can do the testing work for you, if you want. http://www2.saout.de/gentoo/php/
(In reply to comment #6) > Redhat for example (which seems to have borrowed the patches from SuSE in turn). > Thanks Christophe, had seen these and was testing a modified version. Unfortunately I got some compile failures with certain USE flags that I wasn't able to track down. I'll have another look.
You can send me this patchset you put together and I can have a look at them and see if I can track these problems down.
I can confirm the the new php packages (dev-lang/php-4.4.0) work fine on x86 and amd64 without the no-symlinks profile. I'm using a bunch of PECL and PEAR packages (which I needed to reemerge because of the /usr/lib{,64}/php -> /usr/share/php move). Great work! Just curious, are you planning to provide an upgrade script that does the unmerging/remerging, purging /usr/lib{,64}/php as well as the move from dev-php/PECL-* to dev-php{4,5}/pecl-*? It was a lot of hand work.
(In reply to comment #9) > I can confirm the the new php packages (dev-lang/php-4.4.0) work fine on x86 and > amd64 without the no-symlinks profile. I'm using a bunch of PECL and PEAR > packages (which I needed to reemerge because of the /usr/lib{,64}/php -> > /usr/share/php move). > > Great work! Thanks! :) > Just curious, are you planning to provide an upgrade script that does the > unmerging/remerging, purging /usr/lib{,64}/php as well as the move from > dev-php/PECL-* to dev-php{4,5}/pecl-*? It was a lot of hand work. Yeah, it is on our TODO list to do a little script to help with that (unmerge all old-php stuff and make a list of it, rm -rf /etc/php and the apache mod_php config, reemerge dev-lang/php and then all the extensions/packages you were using etc., that's the idea imo, but there are bigger priorities right now, like packages that still depend on mod_php instead of the virtual, some bugs we've discovered and the transition of the libs in dev-php/, like jpgraph, to the new layout before we take a deeper look at such a script). Best regards, CHTEKK.
Created attachment 68136 [details, diff] try lib64 as well when looking for the actual search patch I tried to fix everything I stumbled upon. The SuSE/Redhat patch was incomplete and generated -L /usr/lib even if it was found in /usr/lib64 which yielded strange problems. At least in my configuration (tried to fix some other path lookups too while I was at it but couldn't test them) he now compiles successfully and doesn't generate false -L/usr/lib or -L/usr/X11R6/lib or -rpath to one of those. Needs to rebuild configure (aclocal fix, aclocal, etc...).
The patch had a small glitch. I've put an updated patch and also one for php-5.0.4 (turned out there wasn't much difference in the config system) here: http://www2.saout.de/gentoo/multilib/php/ There's also a trivial gcc 4 compile fix for php 5 (caused an "invaled lvalue assignment" error). And I noticed yet another problem: When rebuilding the configure script (libtoolize, autoconf e.g. with hardened-php) using libtool 1.5.20 he tries to link against /opt/blackdown-jdk-1.4.2.02/jre/lib/amd64/libjava.so instead of the one in /usr/lib64. The reason is that the older libtool had a bug that made it use the one in /usr/lib64 first despite of the -L/opt/blackdown-blabla one the cmdline. Setting EXTRA_LDFLAGS="${EXTRA_LDFLAGS} -L/usr/$(get_libdir)" and the ssame for EXTRA_LDFLAGS_PROGRAM works around that. Only happens with php 4.
(In reply to comment #12) > The patch had a small glitch. I've put an updated patch and also one for > php-5.0.4 (turned out there wasn't much difference in the config system) here: > http://www2.saout.de/gentoo/multilib/php/ Ok, big thanks for this! I'll check them tomorrow, btw I did a quick once-over, why are in the php5 patch some files (var_unserlializer.c or url_scanner_ex.c for example) completely deleted? I'm not positive this is needed for 64bit compatibility, but not sure, don't have 64bit systems atm to test on. And those two patches you're postive fix all extensions? > There's also a trivial gcc 4 compile fix for php 5 (caused an "invaled lvalue > assignment" error). Yup, this was confirmed and tested, the patch works, big thanks for this, it will be applied to the overlay soon! > And I noticed yet another problem: When rebuilding the configure script > (libtoolize, autoconf e.g. with hardened-php) using libtool 1.5.20 he tries to > link against /opt/blackdown-jdk-1.4.2.02/jre/lib/amd64/libjava.so instead of the > one in /usr/lib64. The reason is that the older libtool had a bug that made it > use the one in /usr/lib64 first despite of the -L/opt/blackdown-blabla one the > cmdline. Setting EXTRA_LDFLAGS="${EXTRA_LDFLAGS} -L/usr/$(get_libdir)" and the > ssame for EXTRA_LDFLAGS_PROGRAM works around that. Only happens with php 4. Hmm I'm currently working on the whole auto-stuff since Hardened-PHP needs some love to work in that way. :) After I commit the fixes to SVN you can test again please, and if it persists maybe submit a little patch? Since I didn't really get 100% the fix, is this to be done generally or only in the java ext? Thanks for info, and big thanks for all the work! :) Best regards, CHTEKK.
> > http://www2.saout.de/gentoo/multilib/php/ > > Ok, big thanks for this! I'll check them tomorrow, btw I did a quick > once-over, why are in the php5 patch some files (var_unserlializer.c or > url_scanner_ex.c for example) completely deleted? Sorry, this is crap. A patch without any parameters creates .orig files which I then delete, but there are some in the php tar file which then got diffed away. I've remade the patch. > And those two patches you're postive fix all extensions? At least all I was using and I have nearly everything activated. I'll do a quick check if I missed anything later on. > Hmm I'm currently working on the whole auto-stuff since Hardened-PHP needs > some love to work in that way. :) After I commit the fixes to SVN you can test > again please, and if it persists maybe submit a little patch? Okay, sure. > Since I didn't really get 100% the fix, is this to be done generally or only > in the java ext? php 4.4 uses -L/opt/blackdown-blabla for the whole build process and the final linking stage and that's where he fails then when trying to link against -ljpeg, which is caused by the build-in gd ext. Adding the library search path -L/usr/lib{,64} before the others make libtool finde the real libjpeg.so again. > Thanks for info, and big thanks for all the work! :) You're welcome. It's always fun to help out with new exciting development stuff. :)
> I've remade the patch. > At least all I was using and I have nearly everything activated. I'll do a quick > check if I missed anything later on. Ok thanks for this. > > Hmm I'm currently working on the whole auto-stuff since Hardened-PHP needs ... I finished that the other day, and it seems to work really well now, PHP 4 and 5 compile with Hardened-PHP and GD/Jpeg et all, and "fastbuild" too work with Hardened-PHP now, also it seems that Hardened-PHP now finally cooperates well with Apache/Apache2, so that block was also removed since I could not reproduce any problem atm. Please test the new dev-lang/php ebuilds in the PHP Overlay [1] (they will go into Portage in a few days, still need some testing, especially by you :P). I'll take a closer look at the amd64 search-path patches tomorrow, when I'm sure all the other changes work without problems. Thanks again for the help in this. :) Best regards, CHTEKK. [1] http://svn.gnqs.org/projects/gentoo-php-overlay/
Yes, I can confirm that php-4.4.0{,-r1} and php-5.0.[45]{-r1} compile fine on AMD64 with those combinations. The linking problem is gone, fastbuild and/or hardenedphp are fine for cgi, apache2 and cli. As for my patches: I think I got all extensions that the ebuild is allowing to build, just some exotic ones might be missing. I don't know if those actually have lib64 subdirectories as they are usually not installed into the system libdirs (like Oracle and such). And they don't collide with any of the other patches. Some minor trivial fixups were needed for php-5.0.5 (from 5.0.4).
Reopening this since the lib64 patch still needs to be reviewed and applied to dev-lang/php, sorry for the delay, will try to finish this during the week. Best regards, CHTEKK.
php herd: ping
A little late, but: pong. :) I've added the new revisions/versions of dev-lang/php today to the tree wich include the multilib patches from Christophe Saout, wich I updated for the new PHP versions and checked to fix also some missing extensions, it should now work on multilib-strict profiles, but I have no means to test it, so if you please could, thanks! Marking this as test-request in the meantime. Best regards, CHTEKK.
Works for me, thanks both Luca and Christophe.
