Technically no. I forgot all the exact reason for the static linking,
but I know one of them was that it was easier to maintain an "official"
version that was included with the PHP release. The other reason had to
do with easing the installation burden and all the problems people have
in that area with dlls. Can't remember if there were others.
At this point, I have no problems with going back to using dlls (as long
as this includes libxslt as well). Previously I leaned more towards
statically including them, but in this situation it might make more
sense to just do the dll thing. The burden now would fall more on Edin
and people supporting windows installations as this changes things a bit.
One thing to note is that if we do go ahead and switch to dlls for both
of these, my builds for libxml2 and libxslt will no longer be needed
(though I'll still supply release and debug builds for anyone who wants
them). Be aware of the following that we must handle if using any of the
other libxml2 binaries (built with any of the post VC6 compilers):
http://mail.gnome.org/archives/xml/2004-March/msg00187.html
I have been building the libs using VC6 just to avoid having to deal
with this.
I we go the dll route, does this mean we change it in all branches? Do
we also change domxml in PHP 4 to link dynamically?
I really dont know if domxml causes a problem with win 2003 and believe
it is linked statically within that dll.
Rob
Andi Gutmans wrote:
Yep, that makes sense.
Is there a reason why we don't link dynamicall to libxml2.dll? Makes all the
sense in the world IMO and this has always been the common practice.
I'm just worried that messing around with DllMain() will cause some problems
down the road and having libxml2.dll is more flexible.
Andi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
