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

[Igor Zlatkovic <igor stud fh-frankfurt de>]

Hi,

> 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.

Exactly that was the point. The current build compiles the source once and
builds both the static and the shared library from the resulting object
files. Having that macro would require the source to be compiled twice, once
for the static library and once for the shared library.

However, it is the fact that building on Windows takes only a fraction of
time it takes on Linux. This is because the configuration stage is a lot
shorter (a second or two) and C-runtime headers in glibc are by far more
complex than those in MS C-runtime.

Adding another compilation run would still keep the whole build time shorter
than on Unix, so this would not represent a big problem for Windows users,
who anyway wait for the OS to finish stress-testing the hard drive all the
time :-) However, it would require a revision of the makefiles and until
that is done, build would be broken.

Exactly this double-run is something other software needs, for example
Alexey's xmlsec. This and few other projects have used these macros from the
beginning and would directly benefit from the double-run. Since I don't use
xmlsec now and have a myriad of other problems, I haven't found the time to
do it there. If libxml should go the same way, I am basically ready to make
the required change to the makefiles.

I just must remind to the fact that the very reason for the existence of the
.DEF file in libxml was preventing these macros to overbloat the headers.
That was the opinion of most list members back then. Perhaps this has
changed in the meantime?

> (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?

No, nothing. Of course the .def.src is a pain, but at the time it was
needed, it was the solution accepted by most list members.

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

Really? I didn't know that. Doesn't matter, that is the smallest of our
problems. I can quite easily have __WIN32__ defined in the MSVC makefile and
replace all occurences of WIN32 and _WIN32 in the source with that.

Ciao
Igor