On 08/31/2018 11:57 AM, Nick Wellnhofer wrote:
> On 25/05/2018 17:46, Michael Haubenwallner wrote:
>> When an application using libxml2 does not enable multithreaded support
>> for itself, we provide the singlethreaded variables, eventually tagged
>> with dllimport.  So even when we build the multithreaded libxml2, our
>> singlethreaded variables still eventually need the dllexport tag.
> I don't understand the issue. Do you mean an application linked with a DLL 
> configured without thread support and compiled with single-thread headers, 
> and THEN swapping the DLL with a multi-thread version? I'm not sure whether 
> this should be supported.

Actually it's the other way round:
The xml library is configured with thread support, but
the application is created without thread support - with
the application in question being gettext (as of version 0.19.7,
but it's the same even in gettext master still).

Without patching, gettext does explicitly use the --disable-auto-import
linker flag on Cygwin and MinGW, relying on symbols to be dllexport'ed, see

However, the Cygwin distro currently does modify this m4/woe32-dll.m4 to
stay with auto-import enabled, simply to get a working gettext package.

So even when thread support is enabled in xml, it still is useful in
single threaded applications - and xml should support this use case.

Right now, LIBXML_THREAD_ENABLED is defined in xmlversion.h only if the
*application* does enable threads, otherwise the single threaded xml
symbols are declared - which are not dllexport'ed when thread support
is configured for libxml, yet they are still there but auto-imported.

However, another variant might be to declare the threaded symbols when
xml is *configured* with threads enabled, not depending on whether the
application has threads enabled. Beyond that, omitting the single threaded
symbols from the dll may make sense, but that would require a SONAME bump.

xml mailing list, project page  http://xmlsoft.org/

Reply via email to