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. 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.
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. Andi > -----Original Message----- > From: Edin Kadribasic [mailto:[EMAIL PROTECTED] > Sent: Friday, September 01, 2006 2:35 PM > To: Andi Gutmans > Cc: 'Rob Richards'; internals@lists.php.net > Subject: Re: [PHP-DEV] libxml2/threading/win 2003 > > Rob, Andi, > > We need to get issue resolved ASAP, as we are running into > high RCs with > 5.2.0. > > The reason libxml2 is statically linked into php5ts.dll is > our policy that php should be able to run in a basic > configuration (cli or cgi or any other sapi) with nothing but > php5ts.dll. > > Since our basic configuration contains several xml extensions > it was then necessary to link libxml2 into php5ts.dll. > > I think that we should keep this principle since our past > experience tells us that breaking that rule creates massive > problems for users. > > Edin > > > > 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 > > > > > > > >>-----Original Message----- > >>From: Rob Richards [mailto:[EMAIL PROTECTED] > >>Sent: Friday, August 25, 2006 4:26 AM > >>To: Andi Gutmans > >>Cc: 'Edin Kadribasic'; internals@lists.php.net > >>Subject: Re: [PHP-DEV] libxml2/threading/win 2003 > >> > >>MINIT is definitely not the place for this. > >>The xmlDllMain call is meant to be called from within a > dll's DllMain > >>that includes libxml statically. > >>How threads are handled differs between the old static > build and the > >>one for inclusion within a dll. > >>When a thread (all except the main thread) terminate currently > >>xmlDllMain makes sure that everything for the thread is properly > >>cleaned up. > >> > >>When the function needs to be called is really dependant > upon how the > >>PHP dll is loaded (in process, out of process, etc..). I am > not sure > >>of the states running under Win 2003, but from what I guess reading > >>the reports is that it is out of process and a timing issue > when not > >>everything from one of the spawned threads is cleaned up > prior to the > >>main thread being cleanedup. > >> > >>Also right now the function only handles the xmlDllMain > >>DLL_THREAD_DETACH message, but what happens if other > messages need to > >>be handled? > >> > >>The only way to eliminate the need for this call, a DllMain and the > >>new static build of libxml2 is to no longer build it in > staically and > >>use the dynamically loaded libxml2.dll. > >> > >>Rob > >> > >> > >>Andi Gutmans wrote: > >> > >>>Rob, > >>> > >>>Is there a reason why we can't call this from MINIT? I'm > not sure a > >>>good long-term solution is to have a DllMain when we don't > need one. > >>> > >>>Andi > >>> > >>> > >> > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
