Re: [xml] MSYS and MINGW: undefined reference to _imp__xmlFree

[Igor Zlatkovic <igor zlatkovic com>]

On 05/11/09 12:50, Martin Schlemmer wrote:
> Hi,

Ho,

> http://git.gnome.org/cgit/libxml2/commit/?id=a194ccb8d19ddde94c2c04ddf197e6a629f7cc9b

That patch is wrong, of course. Sorry, I guess I didn't look closely
enough when I saw it. It should be reverted or replaced with something
better, as Roumen pointed out.

> As for fixing this issue - I guess the first will be to back out that patch again.  Then I
> have thought about two possible solutions:
> - deal with linking to static without LIBXML_STATIC defined by keep telling people
> to not do that.  As for the failures with xmllint, etc. I can try to help debug that if I
> could get more information about build environment, etc.
> - rather use the approach GLIB and friends use - only allow either static or shared
> builds, and define LIBXML_STATIC via the headers if needed instead of hoping
> the user will remember it
>
> Personally I thought the second approach will be the less painful in future approach,
> and I made a patch as well as tested it in the situations I could think could cause the
> failure.  I also redid the definitions in xmlexports.h to be more like glib's which I think
> is more clear.

If I am not wrong, when I look at your patch, that second approach
results in two sets of headers, one for the dynamic, the other for the
static business. How should the binary distribution look like? Two
packages? One package with two sets of headers? What about that "static
for DLL", when the user builds a shared library which links to libxml2
statically? Do we now have three packages or three sets of headers
there? The user will not have to define LIBXML_STATIC, but will likely
chose a wrong package or a wrong set of headers. Nothing is won.

As for the rest, I am very interested in seeing a working MSYS+MinGW
build which produces libraries usable by Microsoft linker. I am
presently next to unfamiliar with GNU autoconf/automake and given my
dislike for the dreaded build system, I am likely to make myself
familiar with it only in a grave need :) I would be eternaly thankful to
you if you could revise your patch and make the thing work with the
following constraints and freedoms:

1. Don't, under any circumstances, break the build on Linux nor alter
the binary compatibility there or on any OS which has Unix roots. Much
of the world, to name GNOME and KDE as prominent examples, depend on
libxml2 and they will whip our backs til the skin comes off if we affect
them.

2. Resulting libraries must be usable by Microsoft linker. This means
that those forsaken __declspec(dllimport/dllexport) things must be
defined properly for the build of libxml2 itself and the user code.

3. You may alter the output files on Windows, such as naming them
differently (when I last tried, MSYS+MinGW produced a libxml2-2.dll, not
the hoped for libxml2.dll). This is okay. As an orientation: If some
greedy corporation must recompile all their Windows software for the new
libxml2 release, that I don't care about. But if Tor Lillqvist can use
the thing for his GTK and GIMP work without having to tweak it and thus
be able to spend more time with his children, I am all in :)

4. If possible, use the same set of headers for the dynamic and the
static business, even if the user has to do a -DLIBXML_STATIC for the
static part to work. I think it is a small requirement which is easily
met and eases the packaging of binaries.

This now sounds like a whole pile of demands and like I would love to
see it done by someone else. Believe me, if I have had the time to meet
the secrets of GNU autoconf/automake, I would have done it long ago. You
seem to know your way there and can do it much more swiftly than I
could. As a remedy, don't bother with things beneath the win32
subdirectory in the source. Once your patch to autoconf/automake based
build is complete, I'll fix the Windows scripts. Also, I can help you
test your work and see whether my own MSYS+MinGW environment would take it.

If this can work out, I'll do my best to adopt it for the dependants
(libxslt, xmlsec) and dependencies (zlib, iconv, openssl) and my binary
distribution of the whole pack I shall then make with GCC, dropping
MSVC. It would be in everyone's best interest, since my binaries are
quite widely used and noone can reproduce them due to a lack of my
locally patched MSVC.

What do you think?

Ciao,
Igor