Hi, I've been working on packaging maniadrive: http://maniadrive.raydium.org/ This game uses php as embedded script language, in order to do this it needs php build embeddable, resulting in the creation of a libphp5.so I've written a specfile patch (attached) and a lib64 bugfix patch for the php-embedded makefile (will attach) Could you please incorperate this into the rawhide version? I've tested this with maniadrive (no package as of yet, just a manual compile) and it works fine. Since the embedded version gets build in its own build dir, I believe it cannot cause any harm to / regressions in the other versions. Note that the use of a private build dir is necessary, the no chance in harming the other builds is a nice side effects.
Created attachment 160984 [details] specfile patch implementing an embedded subpackage
Created attachment 160985 [details] PATCH: fix lib64 bug in embed module Makefile
Thanks for the patches. 1) I presume you are planning to package an application which uses this in Fedora? 2) Putting the generated libphp5.so in libdir is slightly odd. Does the application link against this at runtime (i.e. dlopen) or at build time? If the latter this needs a .so.N and a SONAME etc as for any normal library. If the former it shouldn't be in libdir directly, really.
(In reply to comment #3) > Thanks for the patches. > > 1) I presume you are planning to package an application which uses this in Fedora? > Yes. as said: "I've been working on packaging maniadrive: http://maniadrive.raydium.org/ " > 2) Putting the generated libphp5.so in libdir is slightly odd. Does the > application link against this at runtime (i.e. dlopen) or at build time? If the > latter this needs a .so.N and a SONAME etc as for any normal library. If the > former it shouldn't be in libdir directly, really. It links against it at build time: [hans@shalem ~]$ ldd ManiaDrive-1.2-src/mania linux-vdso.so.1 => (0x00007fffc1dfd000) libode.so.0 => /usr/lib64/libode.so.0 (0x00002aaaaacc7000) libGLEW.so.1.4 => /usr/lib64/libGLEW.so.1.4 (0x00002aaaaafa1000) libalut.so.0 => /usr/lib64/libalut.so.0 (0x00002aaaab1e3000) libphp5.so => /usr/lib64/libphp5.so (0x00002aaaab3eb000) libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00002aaaab97c000) libopenal.so.0 => /usr/lib64/libopenal.so.0 (0x00002aaaabb9d000) libXinerama.so.1 => /usr/lib64/libXinerama.so.1 (0x00002aaaabde9000) <more libs snipped> I'll do an updated version of the Makefile patch to add a proper soname and version the filename, do you have suggestions for the soname, I'm thinking about using the following as both lib and soname: libphp-%{zendver}.so And then adding a libphp.so symlink for linking, in I guess <sigh> a php-embedded-devel package Notice that in this case there is no reason to put a version behind the .so as the version is in front of it, this is equal to libtools behaviour when specifying -release x.y.z when linking instead of using -version-info x.y.z, this is used for (BAD) libs which break there ABI all the time. Note: I'm not saying that php is such a bad lib, but I just think this is the sanest versioning scheme for the .so, so that any breakage will be detected, without forcing unnecessary breakage, as for example using libphp-%{version}.so would do. Please let me know if libphp-%{zendver}.so + libphp.so symlink in php-embedded-devel is acceptable, then I'll start working on an updated patch asap (and if its not acceptable suggestions are very much welcome).
Hmm, I've been doing some more digging and it seems that the interface of / too libphp5.so could change without zendver changes as libphp5.so exports (and users use) much more then just the PECL / zend module API. So maybe it would be best to build libphp5 static, and add a: Requires: php-soap, php-zend-abi = %{zendver} To packages linking against libphp5.a Because afaik the modules provided by php-common should keep working with the php from libphp5.a as long as php-zend-abi doesn't change, just like external modules should / would. Alternatively we could use: libphp5-%{version} as lib and soname, but then using packages would need to be rebuild each new upstream version. This would mean that when a security update gets issued, and a user has a libphp5.so using package, that yum update will fail (leaving the user vulnerable) until the using package gets rebuild. OTOH the chances of someone installing something like ManiaDrive on a php equiped server is very small. And one more option would be to staticly compile the needed php modules (soap) into libphp5.a and forget about any deps / ABI issues. They all have advantages and disadvantanges, let me know what you think / which way you want to go.
Thanks for looking into this, Hans! 1) Yes, the ABI is not stable or versioned at all at this level, so I agree with using "libphp5-%{version}.so" as the soname. 2) It is the case that when the version changes, users of the library will have to rebuild, so the ABI versioning must reflect that. Sometimes we do use backported patches for PHP in Fedora, so it's not always the case that a security update will require a lock-step rebuild of dependant packages. 3) I'm not sure there's really a need for an -embedded-devel subpackage just to contain a libphp5.so symlink; I'd say just put it in -embedded too. (maybe Provide: php-embedded-devel for consistency/forward-compatibility?) 4) I'd very much rather not have a static library, for all the usual reasons.
Created attachment 161075 [details] Updated php Makefile / config.m4 patch for php-embedded building (In reply to comment #6) > Thanks for looking into this, Hans! > > 1) Yes, the ABI is not stable or versioned at all at this level, so I agree with > using "libphp5-%{version}.so" as the soname. > Ok, that was my prefered solution too, the just attached patch makes the necessary buildsystem changes. I'll attach an updates spec patch next. > 2) It is the case that when the version changes, users of the library will have > to rebuild, so the ABI versioning must reflect that. Sometimes we do use > backported patches for PHP in Fedora, so it's not always the case that a > security update will require a lock-step rebuild of dependant packages. > Ok, if thats not a problem to you then I'm fine with it. > 3) I'm not sure there's really a need for an -embedded-devel subpackage just to > contain a libphp5.so symlink; I'd say just put it in -embedded too. (maybe > Provide: php-embedded-devel for consistency/forward-compatibility?) > Ok, for now I've put the symlink in the php-embedded package and added a: Provide: php-embedded-devel But I'm pretty sure this will get us in trouble with the guidelines police as it doesn't follow the guidelines. Also, now to use php-embedded one must do: BuildRequires: php-devel php-embedded-devel I would rather see a real php-embedded-devel with the symlink in it and make that require php-devel, so that a package building against php-embedded-devel can just say: BuildRequires: php-embedded-devel > 4) I'd very much rather not have a static library, for all the usual reasons. > I agree, but I was afraid you might not like the lock-step rebuild of dependant packages requirement, so I made up some alternatives which didn't need this.
Created attachment 161076 [details] specfile patch implementing an embedded subpackage
Looks great, thanks a lot. I submitted a build, but configure failed on ppc64, probably an unrelated issue. I'm away next week so I'll look at it after then. Feel free to resubmit a rebuild in the mean time (access control permitting). http://koji.fedoraproject.org/koji/taskinfo?taskID=96987
The problem was in glibc causing a libstdc++ link problem and is fixed now, so I've build this now, closing: http://koji.fedoraproject.org/koji/taskinfo?taskID=97540
One last note, while looking at how mandriva does certain things with regards to maniadrive, I also wondered how they were doing the php stuff. They use a shared libphp5_common.so with the php core, which seems to be shared between the cgi and apache module. This _might_ be something for Fedora too, see: http://cvs.mandriva.com/cgi-bin/viewvc.cgi/SPECS/php/php-5.1.3-shared.diff?revision=1.1&view=markup http://cvs.mandriva.com/cgi-bin/viewvc.cgi/SPECS/php/php.spec?revision=1.130&view=markup