ohnopublishing drupal # eselect php set apache2 1 You have to run `/etc/init.d/apache2 restart' for the changes to take effect ohnopublishing drupal # rc-service apache2 restart apache2 | * apache2 has detected an error in your setup: apache2 |apache2: Syntax error on line 175 of /etc/apache2/httpd.conf: Syntax error on line 4 of /etc/apache2/modules.d/70_mod_php5.conf: Cannot load /usr/lib64/apache2/modules/libphp5.so into server: /usr/lib64/apache2/modules/libphp5.so: cannot open shared object file: No such file or directory apache2 | * ERROR: apache2 failed to start ohnopublishing drupal # ls -lha /usr/lib*/apache2/modules/libphp5.so lrwxrwxrwx 1 root root 36 Jul 13 07:51 /usr/lib32/apache2/modules/libphp5.so -> /usr/lib32/php5.3/apache2/libphp5.so The problem is that apache2 looks for modules in /usr/lib64/apache2/modules and looks for a 64-bit version. So, it's all nice and cool that /usr/lib32 is supported, but you have to support more than that ;-). One reason it doesn't support my setup might be that /usr/lib isn't a symlink when people would prefer that I make it one. list_libdirs() comes up with libs in the order of lib, lib32, lib64. If /lib and /usr/lib were symlinks, the first apache2 directory eselect-php would come upon would be correct, but on my system it isn't. I will see if I have time to write a patch later, for now I'm just going to sham in a manually created symlink. P.S., it would always be nicer if the symlinks were relative than absolute too... ;-). That way, the symlink itself wouldn't even have to contain the ABI-specific libdir name and there'd be less of a need for a $(get_libdir) to choose one specific libdir to return...
I actually tried to support multilib without the /usr/lib symlink. However, earlier on, I got an issue that was the exact opposite. The eselect module symlinked the 64-bit version, while apache wanted the 32-bit version. I have no idea what is the correct way of determining which version apache want.
(In reply to comment #1) > I have no > idea what is the correct way of determining which version apache want. The best way is to just setup all libdirs and let apache choose which version it wants ;-). I've started writing a patch which makes eselect-php do this, hopefully I'll have time tonight to finish it and attach something.
Created attachment 280691 [details, diff] eselect-php-0.6.4-multilib.patch This fixes php's apache2 support on my multilib machine. It also works OK for cli and cgi. I don't know what fpm is. This patch also makes all of the symlinks relative instead of absolute. That reduces the amount of times the libdir has to occur in the symlink's path. So at least a working apache2+php setup can be gotten on a portage-multilib machine now :-). The remaining problem is how eselect-php shirks around portage-multilib's abi-wrapper. For non-multislotted apps and if there is a reason to have a multilib binary, such as for appname-config binaries/scripts, /usr/bin/appname-config is set up as a symlink to /usr/bin/abi-wrapper. /usr/bin/abi-wrapper will looks for /usr/bin/appname-config-${ABI}, defaulting to the machine's native ABI. This allows the 32-bit version of appname-config to be invoked by, say, a 32-bit compilation's ./configure script for another package which uses appname. php installs even binaries into slotted and ABI-protected directories, which I think is a valid practice. So, what I'm saying is that there's currently no way to make $ ABI=x86 php-config translate into running /usr/lib32/php5.3/bin/php-config and $ ABI=amd64 php-config translate into /usr/lib64/php5.3/bin/php-config. And just for sake of completeness, since a 32-bit version of the php binary itself is installed, it might make sense to support `ABI=x86 php'. So, any thoughts on that? In the meantime, my current patch does fix stuff and would be helpful for portage-multilibers ;-). Maybe a proper solution to this problem will require extending eselect's /usr/share/eselect/libs/multilib.bash script to recognize the values which the ABI variable can hold instead of just having the hardcoded string of "lib lib32 lib64".
Thanks for the patch. It looks fairly straightforward. I'll look into creating a new release soon. It would be interesting to support wrapping the PHP binaries to support multilib, but I fear it may make PHP maintenance even more complicated without really supporting a larger user base. FPM is the 'new' PHP SAPI that all the cool kids use, together with servers like nginx.
How's the new version coming along? I was just looking at closing bug #356467 but found we need a stable >eselect-php-0.6.2 for this. How about aiming for a stable eselect-php-0.6.5 next month?
Oh my. My brain believed I had already created this release. I'll have it done tomorrow.
Committed.
