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

["Ed Day" <eday obj-sys com>]

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