Everything

php

libxml2/threading/win 2003

php.internals

Rob Richards

20 years ago

In order to resolve reported crashing on win 2003, I have had to change
the static libxml builds to use the flag LIBXML_STATIC_FOR_DLL.

This now requires a DllMain to be added within any dll that is building
libxml2 in statically.
PHP 4.x - domxml (use php_domxml.c.diff.txt patch)
PHP 5.x/HEAD added within libxml.c (apply libxml.c.diff.txt to PHP 5 and
HEAD - was made against HEAD)

This changes the threading a bit to work in the same manner as if
libxml2 were built and linked to as a shared lib.

Along with these changes new libxml libraries are needed.
debug builds:
http://ctindustries.net/libxml/libxml2-2.6.26.threads.zip
http://ctindustries.net/libxml/libxslt-1.1.17.debug.php.zip

release builds:
http://ctindustries.net/libxml/libxml2-2.6.26.threads.zip
http://ctindustries.net/libxml/libxslt-1.1.17.php.zip

So far I have been testing these against 5.2 builds and ran a few tests
with domxml in PHP 4.4 to make sure all was good. I would appreciate it
if anyone running win builds make these changes to their local builds
and let me know if anyone runs into any problems (there really shouldnt
be any, but in any case..). Would like some additional outside testing
before committing this stuff.

Rob

Edin Kadribasic

20 years ago

Hi Rob,

Since we're adding a DllMain function, shouldn't it be located in
main/main.c. We might need to hook up other thread initialization stuff
in there in the future.

Edin


Rob Richards wrote:

Rob Richards

20 years ago

Doesn't really matter where it is. The only reason I added it in
libxml.c was since libxml2 was the first/only lib needing a DllMain in
teh php5ts_xxx.dll build, I put it there so there was minimal changes to
the core code.
Evenutally I thought it might make more sense to me moved elsewhere so
other extensions could (if needed) take advantage of it.

Rob

Edin Kadribasic wrote:

Rob Richards

20 years ago

Now that 5.1.5 and 4.4.4 have been released, is it possible to get these
changes and updated lib in?
Ilia, not sure if this interrupts your RC schedule at all, but this
change should resolve many of the windows crashes reported under 2003,
so would like to get this into 5.2.

Rob

Edin Kadribasic wrote:

Andi Gutmans

20 years ago

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

Rob Richards

20 years ago

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:

Andi Gutmans

20 years ago

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

Rob Richards

20 years ago

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:

Steph

20 years ago

Hi Rob,

Wasn't there something with iconv too that was affected by libxml being
statically linked?

(I might be confusing myself with blurred memories here, it was a long time
ago.)

- Steph

Edin Kadribasic

20 years ago

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:

Andi Gutmans

20 years ago

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

Rob Richards

20 years ago

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

Andi Gutmans

20 years ago

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.

Steph

20 years ago

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

Andi Gutmans

20 years ago

We need to fix that then. And we might need to do something a bit smarter
for php5isapi.dll. I'll think about it but need to leave now for the
weekend. I don't think my explanation covered this issue but only the CGI.
I prefer trying to resolve the issues in a long term way than making the
wrong decision now re: bundling.

Andi

Rob Richards

20 years ago

Andi Gutmans wrote:

> 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.
>
>

Not that I am trying to squash the use of dlls here, but I'm not sure
you are following me.

Why would the dll in the directory with the php5ts.dll take precedence
over another version of the lib somewhere else?
For instance, under apache, some other module is loaded  first that also
happens to use libxml2.dll (and happens to include it within its
directory). If this module gets loaded before PHP, what would the search
order for the dll be then. I assume its own directory and then the
windows directories. PHP would then end up using the other dll (already
being loaded into the apache space) and not the one in its own
directory. Same would then hold true for the iconv, etc.. CLI on the
other hand would (at least should) always use the one within the PHP
directory.

Rob

Nuno Lopes

20 years ago

> Not that I am trying to squash the use of dlls here, but I'm not sure you
> are following me.
>
> Why would the dll in the directory with the php5ts.dll take precedence
> over another version of the lib somewhere else?
> For instance, under apache, some other module is loaded  first that also
> happens to use libxml2.dll (and happens to include it within its
> directory). If this module gets loaded before PHP, what would the search
> order for the dll be then. I assume its own directory and then the windows
> directories. PHP would then end up using the other dll (already being
> loaded into the apache space) and not the one in its own directory. Same
> would then hold true for the iconv, etc.. CLI on the other hand would (at
> least should) always use the one within the PHP directory.
>
> Rob

That was happening for me with the mysql extension. I had the mysql dir in
the path and php was loading the libmysql.dll from there. The result? a nice
crash on startup.
This happened because the mysql dir was before of the php dir on the path.

Anyway, I might see the need to move some librarys to dlls.

Nuno

Edin Kadribasic

20 years ago

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.
> 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.

The most optimal way to make the Windows build has been discussed on
this list several times during the past 3-4 years, including the
question which extensions are built in and what libraries to link
statically. The design that we came up with has been serving us well
during that time.

Having 5-10 dlls that you need to ship just to run "Hello world" and
having to put them in PATH for everything but CGI is suboptimal. Not to
mention the fact that there are colissions with other free software that
uses the same libraries.

Since PHP 5.0 we are not bundling MySQL for example. If you were reading
bug reports you would know how just that one de-bundled lib created a
lot of trouble and confusion among our users.

Edin

Andi Gutmans

20 years ago

Well I suggest to stick to status-quo for 5.2 and then let's discuss if/how
to fix after that.
Statically linking libxml2 is yucki, and due to the reason that it's not
common practice on Windows systems you also have the DllMain issue.