Re: [xml] windows static for dll builds

[Rob Richards <rrichards ctindustries net>]

Igor Zlatkovic wrote:
> On 22.08.2006 13:45, Rob Richards wrote:
>   
> > 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?
>   
Currently there is no prototype in the header file so it doesn't 
indicate the type of linking and I was trying to get this to work 
without affecting other areas. By changing it to XMLCALL, I was able to 
get away not having to add a prototype to the header (though I would get 
a compiler warning in some cases when linking in some cases). Adding the 
prototype, as is, requires the windows.h file, but that leads to 
conflicts in catalog.c (macro redefinitions).
Without having to dive into catalog issue, I guess the prototype could 
be written something like:
int XMLCALL xmlDllMain(unsigned short hinstDLL, unsigned long fdwReason, 
void *lpvReserved);
...or just leave it without a header and change the WINAPI to XMLCALL

As it seems there are few to no others using the static for dll build, I 
was leaning to making the fewest changes possible.
>   
> > 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.
>   
It was decided a few years back to build statically and I never ran into 
problems until IIS on Win 2003 - thus requiring this change in builds.
>   
> > 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.
>   
Wasn't sure what anyone would think of the 3 lib idea so have been just 
building 1 static lib depending which one I needed and calling it 
libxml2_a.lib
>   
> > 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.
>   
Thanks. My intentions are to get it integrated with the rest of the 
build seamlessly. Just to be clear, this is a bit of a selfish request. 
I am just trying to make it easier for someone else to be able to build 
the library without having to learn all the voodoo or always having to 
rely on my releases.

Rob