How can you prepare my new extension source code and/or links so that
the DLL can support all the PHP 5.x.x versions?
I have been trying to figure this out, reading/googling, etc, but in the
mean time what I had to do was recompile the extension for all PHP
releases, 5.04, 5.10, 5.12, 5.25 and now 5.26 and provide each one for
users to select during installation of the extension.
TIA
--
Hector Santos
Hi,
How can you prepare my new extension source code and/or links so that the
DLL can support all the PHP 5.x.x versions?
You can't. But you can have one source version which can be built
against all PHP versions.
I have been trying to figure this out, reading/googling, etc, but in the
mean time what I had to do was recompile the extension for all PHP releases,
5.04, 5.10, 5.12, 5.25 and now 5.26 and provide each one for users to select
during installation of the extension.
The rules are relatively simple, each minor (5.1.x, 5.2.x, 5.3.x)
upgrade breaks binary compatibility. That means you will have to
rebuild your extension to get it work with a given version. So the way
you choosed now is the right one. Please note that you aslo need one
for debug and non debug version.
Cheers,
Pierre Joye wrote:
Hi,
How can you prepare my new extension source code and/or links so that the
DLL can support all the PHP 5.x.x versions?You can't. But you can have one source version which can be built
against all PHP versions.I have been trying to figure this out, reading/googling, etc, but in the
mean time what I had to do was recompile the extension for all PHP releases,
5.04, 5.10, 5.12, 5.25 and now 5.26 and provide each one for users to select
during installation of the extension.The rules are relatively simple, each minor (5.1.x, 5.2.x, 5.3.x)
upgrade breaks binary compatibility. That means you will have to
rebuild your extension to get it work with a given version. So the way
you choosed now is the right one. Please note that you aslo need one
for debug and non debug version.
Ok, but I would swear I was able to use older 5.x.x 3rd party extensions
that still work with each 5.x.x revision. Was that just Luck? For one
package, I spoke with the author because of a bug I found and he
indicated he had to plans to update his package but I was welcome to do
it. I got the source and noticed no real difference in the extension
basic framework. But nonetheless, the older extension did worked with
newer v5.x.x installations I have so I figure it was possible. No PHP
version mismatch loading error which is what I get.
--
Hector Santos
Ok, but I would swear I was able to use older 5.x.x 3rd party extensions
that still work with each 5.x.x revision. Was that just Luck? For one
package, I spoke with the author because of a bug I found and he indicated
he had to plans to update his package but I was welcome to do it. I got the
source and noticed no real difference in the extension basic framework. But
nonetheless, the older extension did worked with newer v5.x.x installations
I have so I figure it was possible. No PHP version mismatch loading error
which is what I get.
I have serious doubt that you are able to load a 5.0.0 DLL with 5.2.x
or a 5.2.x DLL with 5.0.x.
Cheers,
Pierre Joye wrote:
I have serious doubt that you are able to load a 5.0.0 DLL with 5.2.x
or a 5.2.x DLL with 5.0.x.
You're right. I just doubled checked the package and it indeed had
multiple dll extensions per version, in this case 4.0, 5.0, and 5.1.
Thanks for the confirmation.
--
Hector Santos
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
How can you prepare my new extension source code and/or links so that the
DLL can support all the PHP 5.x.x versions?You can't. But you can have one source version which can be built
against all PHP versions.
This is not true. It is possible to create an extension that loads and
works in all PHP versions, but it is a PITA to write it.
If you really want to do this you need to internally support different
binary versions of PHP and you need to replace the get_module export
with your own code that exports different structs depending on PHP version.
Ah yes, and you need to load many symbols through the libc because they
might not exist in the PHP version. f.e. globals...
Stefan Esser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkgmxuwACgkQSuF5XhWr2ni3VgCglNM7Ve6FXfHhG8vKcXyRCgMy
tMwAnj6Q+G0cZEV6bzSi4yPQuEJa9zgl
=WCeY
-----END PGP SIGNATURE
hi,
On Sun, May 11, 2008 at 12:14 PM, Stefan Esser
stefan.esser@sektioneins.de wrote:
How can you prepare my new extension source code and/or links so that the
DLL can support all the PHP 5.x.x versions?You can't. But you can have one source version which can be built
against all PHP versions.This is not true. It is possible to create an extension that loads and
works in all PHP versions, but it is a PITA to write it.If you really want to do this you need to internally support different
binary versions of PHP and you need to replace the get_module export
with your own code that exports different structs depending on PHP version.Ah yes, and you need to load many symbols through the libc because they
might not exist in the PHP version. f.e. globals...
And now try the same on windows :) It is also possible to use 2k5/8
binaries with VC6 binaries but that's a call for troubles.
It is often possible to do many things (even different architecture
support) on unix/linux and sometimes with windows. But we don't
support that, that's what I meant with "you can't". I should have
said: "You can but it is not supported" :)
Cheers,
Pierre Joye wrote:
hi,
It is often possible to do many things (even different architecture
support) on unix/linux and sometimes with windows. But we don't
support that, that's what I meant with "you can't". I should have
said: "You can but it is not supported" :)
You should of said this from the beginning. :-)
Look, I'm new to PHP development only!! <g> I'm not the type to step
on toes, nor buck the system, but I prefer the technical details.
Technically, IMO, I can understand binary conflicts with 5.x vs 5.y, but
not with 5.x.a and 5.x.b. These should be binary compatible updates.
If not, then increase x.
Just imagine the productivity and support gains when you don't have to
recompile for very simple minor update.
Again, I am not here to buck the system. But if I can make suggestions,
I will. :-)
--
Hector Santos
It is often possible to do many things (even different architecture
support) on unix/linux and sometimes with windows. But we don't
support that, that's what I meant with "you can't". I should have
said: "You can but it is not supported" :)You should of said this from the beginning. :-)
Better late than never =)
Look, I'm new to PHP development only!! <g> I'm not the type to step on
toes, nor buck the system, but I prefer the technical details.Technically, IMO, I can understand binary conflicts with 5.x vs 5.y, but
not with 5.x.a and 5.x.b. These should be binary compatible updates. If
not, then increase x.
It is the case. ABI can be broken between x.y.z and x.y+1.z or x.y.z
and x+1.y..z but not between two bug fixes releases only (z and z+1).
Just imagine the productivity and support gains when you don't have to
recompile for very simple minor update.
Indeed, that's why we have these rules :)
Again, I am not here to buck the system. But if I can make suggestions, I
will. :-)
And they are obviously welcome :)