[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: [xml] Release of libxml2-2.4.19



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]