This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 251520 - RFE / PATCH: build embeddable version of php5 (libphp5.so)
RFE / PATCH: build embeddable version of php5 (libphp5.so)
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: php (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Joe Orton
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-09 11:09 EDT by Hans de Goede
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-11 06:44:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
specfile patch implementing an embedded subpackage (3.30 KB, patch)
2007-08-09 11:09 EDT, Hans de Goede
no flags Details | Diff
PATCH: fix lib64 bug in embed module Makefile (634 bytes, patch)
2007-08-09 11:10 EDT, Hans de Goede
no flags Details | Diff
Updated php Makefile / config.m4 patch for php-embedded building (2.43 KB, patch)
2007-08-10 15:38 EDT, Hans de Goede
no flags Details | Diff
specfile patch implementing an embedded subpackage (3.43 KB, patch)
2007-08-10 15:39 EDT, Hans de Goede
no flags Details | Diff

  None (edit)
Description Hans de Goede 2007-08-09 11:09:14 EDT
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.
Comment 1 Hans de Goede 2007-08-09 11:09:14 EDT
Created attachment 160984 [details]
specfile patch implementing an embedded subpackage
Comment 2 Hans de Goede 2007-08-09 11:10:13 EDT
Created attachment 160985 [details]
PATCH: fix lib64 bug in embed module Makefile
Comment 3 Joe Orton 2007-08-09 11:39:02 EDT
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.
Comment 4 Hans de Goede 2007-08-09 15:52:30 EDT
(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).
Comment 5 Hans de Goede 2007-08-09 17:17:05 EDT
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.
Comment 6 Joe Orton 2007-08-10 04:31:18 EDT
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.
Comment 7 Hans de Goede 2007-08-10 15:38:29 EDT
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.
Comment 8 Hans de Goede 2007-08-10 15:39:27 EDT
Created attachment 161076 [details]
specfile patch implementing an embedded subpackage
Comment 9 Joe Orton 2007-08-10 16:32:29 EDT
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
Comment 10 Hans de Goede 2007-08-11 06:44:50 EDT
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
Comment 11 Hans de Goede 2007-08-11 10:57:17 EDT
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

Note You need to log in before you can comment on or make changes to this bug.