Re: [xml] [PATCH] always dllexport the singlethreaded variables

[Michael Haubenwallner <michael haubenwallner ssi-schaefer com>]

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
http://git.savannah.gnu.org/cgit/gettext.git/tree/m4/woe32-dll.m4?h=v0.19.7

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.

HTH,
/haubi/