the depend.apache.eclass sets: APACHE2_BASEDIR=/usr/lib/apache2 modules are going into /usr/lib/apache2/modules This means that shared objecs for different ABI can be overwriting eachother. What is the point of having all this in /usr/lib/apache2? Can apache be modified so it uses: /usr/$(get_libdir)/apache2/modules /usr/$(get_libdir)/apache2/extra-modules I don't want to do these changes myself as it is in an eclass, so I can't restrict the changes to ~amd64.
a multilib apache means also providing a multilib apache binary? Well, I'm having some problems with a related ebuild for a library that I'd like to make multilib aware, but it depends on attr and acl who are *not* multilib aware. How do handle this in Apache? I ask, because apache won't just depend on multilib-aware libs, but if it shall be built multilib aware, all it's dependencies shall be multilib aware, too, shouldn't they? Since I'm having my very own amd64, too, I have some personal interest in getting stepping into all those multilib secrets ;) "LSB-FHS problems": please be more specific, eg tell me where exactly it does *not* conform and how it shall be then (informational href might be welcome :o)
No, a single binary can not be multilib. The only thing here is just putting the binaries (libs) in the correct locations. The LSB-FHS conformance is just that... 64bit shared objects need to go in a subdirectory of /usr/lib64, so doing something like APACHE2BASEDIR=/usr/$(get_libdir)/apache2 should probably work...
Yeah, that's why I asked. My problem is, can apache (64bit version) handle 64bit *and* 32bit module? Is this what you want to get supported? I don't think that it's technically possible without providing two apache2 binaries (64bit and 32bit versions) including all its core modules in both versions. As apache is compiled 64bit on an amd64, the default paths are right (eg. /usr/lib/apache2) since /usr/lib64 is a symlink to /usr/lib) and I even found a 2005.0/non-symlink profile where (I guess, and I hope it is this way) where even no lib64 is no longer in need. Second, In case we change /usr/lib/apache2 to /usr/$(get_libdir)/apache2 in this globally defined variable, it won't break portage (e.g. the main cache generator), will it?
No, a 64bit apache can't use 32bit modules. That's not possible, unfortunately. This is similar to the 64bit mozilla not using 32bit flash plugin issue. That's not what I'm trying to get supported. What I AM trying to get fixed here is just the location of where apache and it's related ebuilds (mod_php, etc) install their libs. 2005.0/no-symlinks makes 3 separate dirs (lib, lib32, and lib64). no-symlinks/no-lib32 makes 2 (lib, lib64) to complete the transition to lib64=64bit, lib=32bit Also, on mips lib = o32, /usr/lib64 = n64 and lib32 = n32. All 3 are different ABIS, so don't rely on things being symlinks... just rely on $(get_libdir) if you are installing binary libs. > Second, In case we change /usr/lib/apache2 to /usr/$(get_libdir)/apache2 in > this globally defined variable, it won't break portage (e.g. the main cache > generator), will it? I don't know well enough ... that's why I'm asking you. As long as the symlinks are there (<=2005.0), it will undoubtedly work, but is there anywhere that strictly references /usr/lib/apache2 in config files, etc? This is really why I filed the bug rather than fixed it myself...
This shouldn't be a problem, technically speaking - it won't break the cache, iirc, or binpkg's (arches can be targetted via CBUILD/CTARGET) so (binpkg) builders should be safe, too. Providing that the above two must-not-be-broken items are not, well, broken, does anyone else have any opinions on this? yay? nay? profit?
Oops, missed one - yes, /usr/lib/apache2 is referenced, but only by /usr/sbin/apxs2, /etc/init.d/apache2 and/or /etc/conf.d/apache2. :-)
beu: so just changing the eclass doesn't help as long as apxs2 and /etc/init.d/apache2 aren't fixed, too (??) What benifits do we have when we change the lines here? Well, I mean, is there any arch than NEEDs these changes in order to compile apache (and related) correctly?
wven when these lines are changed and we pass --libdir=/usr/$(get_libdir) to ./configure, apache ignores it and still installs to /usr/lib. It looks like some changes will be needed to the Makefile.am files to respect @libdir@ and $(libdir) instrad of doing $(eprefix)/lib directly
I may be wrong, but I think changing the config.layout (http://www.gentoo.org/cgi-bin/viewcvs.cgi/apache/dist/2.0/patches/config.layout?root=gentoo-src&rev=1.1&view=auto) using sed-fu before running ./configure may work.... Where does get_libdir come from? do we need in inherit an eclass somewhere, or is it a portage builtiin, or?
inherit multilib will get it for you
beu indicated in the topic of #gentoo-apache that he will be making apache multilib aware on Sunday. any objections and possibly issues need to be presented here before then. beu: before you commit, attach some diffs here so others of us can test the changes...
And... how's it coming? :)
Created attachment 61737 [details, diff] apache multilib fixes I've given this some testing our no-symlinks/no-lib32 profile, seems to work for me. Could use additional testing.
Created attachment 61738 [details, diff] depend.apache.eclass multilib fixes Corresponding patch to the eclass so that additional modules are installed in the right place.
Created attachment 61739 [details, diff] php5-sapi.eclass multilib fix 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. This patch fixes that. Note that php4 has the same problem but is not so easily fixed (heavy patching of the configure script would be neccessary).
Apache herd: I'm happy to commit these changes with your approval. Alternatively I can leave them for you to commit. Please let me know.
The Apache herd doesn't look after PHP packages. Instead of adding php patches here, could you open a separate bug, and assign it to php- bugs@gentoo.org please? Someone will need to produce a multilib patch for PHP4. We expect to support PHP4 for several years to come. Best regards, Stu
Comment on attachment 61739 [details, diff] php5-sapi.eclass multilib fix php patch split to bug 96813, as requested.
uhm, what's the status of this bug?
*** Bug 103987 has been marked as a duplicate of this bug. ***
(In reply to comment #19) > uhm, what's the status of this bug? I've tried mentioning this in #gentoo-apache on a few occasions now but have not received any response. Is there any chance one of the apache herd could look at these patches?
depend.apache.eclass, apache-1.3.33-r12, and apache-2.0.54-r31 are now multilib aware. Please test them.
I've been using the patches posted here for some time now and they were working great. I officially commited ones seem to haved fixed the last small flaws and work fine too. (and BTW: I've also tried the "IWANTTOTRASHMYSYSTEM" experimental amd64 no-symlinks profile and things are working fine too here) Thanks.
