Re: libxml2/threading/win 2003

Andi - the old msi didn't even install extensions. The new one's still in beta. ----- Original Message ----- From: "Andi Gutmans" <andi@zend.com> To: "'Rob Richards'" <rrichards@ctindustries.net> Cc: "'Edin Kadribasic'" <edink@emini.dk>; <internals@lists.php.net> Sent: Saturday, September 02, 2006 5:33 PM Subject: RE: [PHP-DEV] libxml2/threading/win 2003

Yeah but Windows is very friendly and designed for this. As long as the dlls are in the application's directory you will not have problems. This is actually much easier and straightforward than on Linux so it sounds to me that dll clashing problems (which doesn't happen in this case) means that either the .zip or the .msi were just putting the dll not in the right place. That's an easy fix. Seriously, if there's one thing that Windows is good at is in a friendly dll search order. They designed it so that you can keep dlls with the app.

-----Original Message----- From: Rob Richards [mailto:rrichards@ctindustries.net] Sent: Saturday, September 02, 2006 8:17 AM To: Andi Gutmans Cc: 'Edin Kadribasic'; internals@lists.php.net Subject: Re: [PHP-DEV] libxml2/threading/win 2003 I am on the fence one this one. Going the dll route makes my life easier by no longer needing to maintain those builds, but will almost certainly increase the number of bogus bugs to be chased down and cause the windows installation to be more complicated again (Just doing a search you can find tons of people having problems just enabling extensions due to dll requirements). Of course my personal opinion at this point would be to just go the dll route because the burden gets put on someone else then to deal with alot of the issues :) Andi Gutmans wrote:

I don't understand what problems you mean. On the contrary,

statically

linking in everything makes the system extremely unflexible and doesn't allow you to upgrade dlls without having to upgrade

the whole

PHP build. If libxml2.dll is placed in the same directory as php5ts.dll I don't see where the problems would come from.

The problem from the user side always ends up being installation and dll maintenance. It is also quite possible that another module would load a different libxml2 dll, causing XML in PHP to operate differently between running it cli vs under apache. This also requires the iconv dll (assuming that would no longer be statically linked either). It could also require zlib depending up where they got their libxml2 dll from. These were some of the things that statically linking libxml eliminated.

On Windows, performance also isn't impacted by dll vs. non-dll as you'll always have position dependent code and worst case

the linker

will relocate the dll.

Performance issues never factored into the decision.

I feel strongly that statically linking 3rd party libraries and PHP extensions such as PDO into php5ts.dll will lead to more

problems due

to lack of flexibility in people's install. It's a really

bad design

decision and I just don't understand how this happened.

You don't remember the bundling war? It was eventually removed I believe just due to the additional size. The windows build really didn't matter because either the dll needed to be distributed or it would be linked in statically. Rob

-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php __________ NOD32 1.1380 (20060125) Information __________ This message was checked by NOD32 antivirus system. http://www.eset.com