Re: [xml] windows static for dll builds

[Igor Zlatkovic <igor zlatkovic com>]

On 22.08.2006 13:45, Rob Richards wrote:
> I need to start using static builds with the LIBXML_STATIC_FOR_DLL flag 
> and would like to make a couple of changes in order to facilitate 
> building them.

Okay.

> First - change the calling convention of xmlDllMain. I have no idea how 
> (or if) anyone is actually building with this flag, but xmlDllMain is 
> using the stdcall calling convention, while everything else is built 
> using the one specified by XMLCALL making it impossible to link to this 
> function correctly.

Why that?

> BOOL WINAPI xmlDllMain(...
> to BOOL XMLCALL xmlDllMain(
> If anyone in some bizarre manner is somehow actually using this as it is 
> right now, this change would probably break their usage.

That shouldn't break, I guess. All functions state explicitly how they 
should be linked to, but who knows? The really bizarre thing are the 
bewitched build environments which make two different static libraries 
necessary. But, I, highly addicted to dynamic linking, wish to have no 
say in this.

> Next - Right now the Makefile has to be manually edited to add the 
> LIBXML_STATIC_FOR_DLL flag. I would like to add the ability to have this 
> automatically performed by maybe a argument for configure script. This 
> now brings up another question on whether the resulting library should 
> still be called libxml2_a.lib or whether a third library should be 
> produced to be able to distinguish between them (libxml2_a_dll.lib or 
> something along those lines).

Since a directory on the disc cannot contain two files with the same 
name on all known filesystems, it would be good if the name were 
different to what other files in the same directory are called.

> Personally I would like to see all 3 libs built by default and would 
> like to hear anyone's opinion on this (especially since this would 
> affect anyone distributing the binaries by the increase in size).

Those who distribute the binaries will more likely be affected by 
upcoming posts, as users will have just 33% chance to link to the right 
library instead of 50% they have now and, seen statistically, will fail 
more often :)

I could't care less for this static-for-dll thing and have no problems 
with adding another library to the binary distribution, as long it is 
built and packaged in the same breath with the others (see make bindist 
target). If others are at a peace with it, I would say make a patch and 
post it here.

Ciao,
Igor