RE: [xml] Release of libxml2-2.4.19

["Igor Zlatkovic" <izlatkovic daenet de>]

Hello Peter,

> - preprocessor #defines
> Is it intended to have both WIN32 and _WIN32 - and if yes, what's
> the difference

_WIN32 is defined automagically by MS compiler for Win32 targets, perhaps to waken an impression that the 
compiler would support some other targets, which it doesn't. Always defined.

WIN32 is not defined unless you define it on the compiler's command-line. I did this because there are few 
places in the code where WIN32 is used instead of _WIN32. Perhaps I should clean up the source and have it 
check only for _WIN32 thoroughly.

For the time being, you want to ensure both are defined.

> - in threads.c, with threading support disabled and WIN32 (and _WIN32)
> defined, but _MSC_VER not defined, there are two functions referenced 
> but
> not defined:
>  xmlNewGlobalState
>  xmlFreeGlobalState
> Perhaps they are never called, but my linker complains anyway.

Damn me, I don't have the required facilities here to check this now, you'll have to wait until I get home. 
But... if these are called and not defined, then your linker has all rights to complain. If these are not 
called, what kind of reference is it then?

In any case, I can vaguely remember that this part isn't implemented yet. If you use Win32 native threads and 
do not use MS compiler, then you face the code noone I know has compiled or run so far. You can see that the 
code inside _MSC_VER uses a MS proprietary compiler feature to implement TLS. The code which supposed to do 
it without this feature is present, but noone has tested that yet. Now you are our hope, the first one who 
can test it and report problems :-)

The native threading code is however... hm... not exactly ugly, but far from beautiful. Native Win32 thread 
API does not provide a way to specify a destructor function for the TLS data, like pthreads do. The code 
suffers from that fact and works around the problem by creating an extra wait-and-clean thread for each 
application thread which tries to use libxml. I wold suggest at this time to either disable thread support, 
of compile with a pthread implementation, such as http://sources.redhat.com/pthreads-win32/. I am anyway 
tempted to start making binaries which use this library and depend on it.

Ciao
Igor