[xml] Re: Building libxml2 as a DLL under MinGW MSYS (Igor Zlatkovic)


I've recently recompiled libxml2 2.4.23 using Borland's C++ Builder 6, and
after struggling with that I would have to say that one of Elizabeth
Barham's suggestions for MinGW seems very reasonable to me. Specifically, I
think that adding "LIBXML_DLL_IMPORT" to ALL exported functions and
variables makes things a lot simpler than having to deal with the process of
generating a .DEF file. I don't see how it would "break" the current build.
It is fairly simple to define this symbol so that it expands to
"__declspec(export)" when building the DLL, to "__declspec(import)" when
building an application linking to the DLL, and to "" (that is, to an empty
string) when building a static library. (Of course, on most other platforms,
LIBXML_DLL_IMPORT would simply expand to an empty string). This seems far
simpler than the current mechanism of creating (manually?) libxml2.def.src,
then generating a .DEF file from that. Am I missing something?

Also, the macro __WIN32__ is indeed predefined in BCB6. WIN32 and _WIN32 are

-----Original Message-----
From: Igor Zlatkovic <igor stud fh-frankfurt de>
Cc: <xml gnome org>
Subject: Re: [xml] Building libxml2 as a DLL under MinGW MSYS
Date: Wed, 25 Sep 2002 16:47:27 +0200
Organization: UAS Frankfurt

Hi there,

  - Added 'LIBXML_DLL_IMPORT' to all function definitions
    for replacement with __declspec(dllimport) or
    __declspec(dllexport) as needed.

That would break the current build with MS compiler. As 
things fare, that
dllexport while compiling libxml would produce a static library which
reexports all those symbols from the client program. GCC can 
export all nonstatic symbols, so I would suggest to either 
use that feature
or a .DEF file.

  - Same as above
  - Replaced
#if defined(WIN32) && (defined(_MSC_VER) || defined
#if defined(__WIN32__)
    since MinGW compiler doesn't define either of these.

Neither Borland nor Microsoft #define __WIN32__, so that 
change would break
both compilers.

  - disabled libiconv

That file is autogenerated and modifying it brings nothing. 
Besides, perhaps
should the user be the one who decides if she needs iconv or not.

I realize that not all of the changes may require
modification so as to not change any already existing
functionality, but as they stand, they comprise a
sufficient set to allow one to build libxml under MSYS.

Unfortunately, these modifications break other platforms.

There is at least one more person who marches under the same banner. I
suggest you and Elisabeth cooperate in making MSYS/mingw 
work, it would be
the most productive way.


Eric Zurcher
CSIRO Livestock Industries
Canberra, Australia
Eric Zurcher csiro au

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]