RE: [xml] Creating Win32 wrapper function for exported variables

["Vakoc, Mark" <Mark_Vakoc jdedwards com>]

> Not true. The issue is multithreading, not static or dynamic link. MS
> has two C runtime libraries. One is single-threaded (not thread safe)
> and the other is multithreaded (thread safe). The fomer is available
> only as a static library. If you link the C runtime dynamically, then
> you are forced to use the multithreaded version.

Your absolutely right.  I did some more research afterwards and came to the 
same conclusion.  oops.

I also agree we should abandon the LIBXML_DLL_IMPORT.  As it is it seems to
be 
wrong anyway (if you are building libxml, it should be defined as
__declspec(dllexport),
and if you are just linking to the library it should be defined as
__declspec(dllimport).

Regardless, I support maintaining the exports entirely in the .def.src.
While this does require
synchronization with the code, it also makes the code cleaner because the
unix-familiar developers don't have to 
worry about as much win32 considerations (such as when to use
LIBXML_DLL_IMPORT).

Having libraries built and delivered with each release would be helpful.
Perhaps two versions -- each containing a static and dynamic library --
release and full debug.  Each library would also have full functionality
compiled in and would make it easy for those that don't need to custom
configure the components in libxml2.

I've been using libxml2 and libxslt as dynamic libraries for a long time,
but still have some build issues 
with respect the variables, which I thought was a win32 limitation but
evidently not.  I'll do my homework next time.

Daniel, Recently the only real win32 issues I've encountered relate to the
makefiles (.dsp for msvc) and the .def.src.  Maybe there is an easy way to
get changes into these without bothering you?