Re: [xml] wrong compiler settings for MSVC in makefile

["Oliver Stöneberg" <oliverst online de>]

Be careful, if you do so, because the "dllstatic" could be understood 
wrong, because if you want to link the lib statically into a DLL you 
need an additional define to the LIBXML_STATIC. It's the 
LIBXML_STATIC_FOR_DLL define.
I am not sure, if there was an exception in case of "tls" set for 
threads. You have to look-up some discussion around the beta6 time on 
the list. I had a lot of problems with the lib linked statically to 
DLLs in that time and before that. Somebody wanted to add that 
special define at least for documentation reason (was it you, Igor?). 
But hasn't done it yet. 
Also...is there still the obsolete "docb" in the 
configure.js/makefile? Or did they keep it for ABI compatibility.

> I will second Oliver's request for alternate run-time library options.  Lots
> of applications (particularly embedded) need true static libraries.  I would
> propose the that what you are currently calling "static" should be changed
> to "dllstatic" because that is what it is: a static library for linking
> DLL's (good for little else).  There should be three options: static, static
> multi-threaded (which could be a combination of the existing static and
> threads options) and DLL static.  These would use the -ML, -MT, and -MD
> compile options respectively.  And, if "debug" is specified, a "d" should be
> appended to the above options - otherwise you get that annoying mismatched
> default libs link error.
>
> If others think this is worthwhile, I can provide the patch to configure.js
> and the skeleton Makefile.
>
> Regards,
>
> Ed Day
>
>
> ----- Original Message -----
> From: "Igor Zlatkovic" <igor zlatkovic com>
> To: <xml gnome org>; <oliverst online de>
> Sent: Monday, November 17, 2003 8:26 AM
> Subject: Re: [xml] wrong compiler settings for MSVC in makefile
>
>
> > > I tried to link the libxml2 statically into an application, but I got
> > > some error messages while trying to link it. It said some symbols were
> > > already defined in LIBCMT.lib. The problem are different runtime library
> > > setting of the lib and the application I am trying to link it in. I took
> > > a look at the makefiles of the libxml2 and recongised it always compiled
> > > it with "/MD", which would be teh "Multithreaded DLL" runtime library.
> > > That's OK, if you compile the libxml2.dll file and the non-static
> > > library. But it's bad for the static lib. So I case of teh static lib it
> > > should be set to "/MT" (Multithreaded), if "threads" aren't set to "no"
> > > or "/ML" if "threads" are set to "no" in the configure.js.
> > > Unfortunately I don't have a diff/patch for it, because I am not quite
> > > sure how to handle different CFLAGS for the static and non-static lib in
> > > the makefile, because they used to use the same.
> >
> > Things are intentionally set the way they are. It is imperative that all
> > libraries, have they debug symbols or not, be they static or dynamic, use
> > the same runtime.
> >
> > When runtimes are different then:
> > - you do a xmlOutputBufferCreateFile(...); and your app will crash.
> > - you do a xmlOutputBufferCreateFd(...); and your app will crash.
> > - you do a xmlFreeDoc(xmlNewDoc(...)); and your app will crash.
> >
> > Standard descriptors like stdin or stdout one might use in above functions
> > are not compatible between available runtimes. Similarily, the FILE*
> > returned from fopen isn't the same in all available runtimes. These
> pointers
> > and file descriptors can be used only by functions in their respective
> > runtimes.
> >
> > Functions like xmlFree are macros which expand to free from the runtime.
> > But, they expand to free from your runtime, not libxml's runtime. As it
> > appears, malloc from one runtime is not compatible to free from another.
> >
> > Another issue is compatibility between binaries produced by different
> > compilers, msvc and mingw for example.
> >
> > To avoid all kinds of problems, I had to settle for one runtime and use it
> > exclusively everywhere. This implies that all applications which are based
> > on the binaries I produce must use the same runtime. I decided to use
> > msvcrt.dll and I never regretted it. Now, there are too many apps out
> there
> > to break by changing it.
> >
> > First ask yourself if you really need a different runtime.
> > 99.999999999999999% requests for another runtime come from people who want
> > it just because it's the default setting in Visual Studio IDE, and so they
> > believe it must be the right way. If your reason is different to that,
> then
> > we can add an apropriate option to configure.js and makefile.msvc to ease
> > the build with a different runtime.
> >
> > Ciao,
> > Igor
> >
> > _______________________________________________
> > xml mailing list, project page  http://xmlsoft.org/
> > xml gnome org
> > http://mail.gnome.org/mailman/listinfo/xml