[xml] libxml2 and problems with Borland's handling of DLLs

[Eric Zurcher csiro au]

Hello all,

I'm new to the libxml2 world, so I may be raising an old issue, but here
goes...

I'm trying to make use of the libxml2 DLL with Borland compilers (both
Delphi and C++ Builder). This is mostly working beautifully, but there seem
to be some problems which I think are related to the way Borland handles the
importing of symbols from DLLS. It appears as if the Borland compilers do
not "know" about DATA in DLLS - only about functions. If fact, the Delphi
help categorically states that "Global variables declared in a shared
library cannot be imported by an Object Pascal application". The C++Builder
documentation is less clear, but seems to have a similar constraint.

This becomes a critical problem chiefly with the memory management
functions: xmlFree, xmlMalloc, xmlRealloc, and xmlMemStrdup (but note that
it also affects access to other variables, such as xmlParserVersion). These
memory "functions" are actually pointers to the functions themselves.

What appears to be happening is pretty confusing. For every symbol in the
DLL, the linker apparently generates a JMP instruction to that entry point
(even when the symbol points to data, rather than a real entry point).
References to the symbol within the compiled code then all point to that JMP
instruction. But the compiler "knows" that "xmlFree" (to take an example) is
a pointer to a function, and must be dereferenced to get the function's
actual entry point. However, thanks to the linker's behaviour, "xmlFree" now
points to a JMP instruction, rather than the address of a function. The
executing code tries to treat the JMP instruction as part of an address,
which usually results in an access violation. Not good.

I can get around this by never calling xmlFree directly, but using my own
function which calls xmlMemGet to determine the current deallocation
function's address, then making use of that function, as in:

void myXmlFree(void* memPtr)
{
   xmlFreeFunc freeFunc;
   xmlMemGet(&freeFunc, 0, 0, 0);
   (*freeFunc)(memPtr);
}

Is there a better solution? 

I note that is libxml2-pas, the problem is handled by replacing the
allocation function with that of the Borland memory manager, and then having
an "xmlFree" function (not the one in the DLL) which directly calls the
Borland deallocation routine. This is not entirely satisfactory for my
purposes. I use libxml both in a main application and in dynamically loaded
DLLs. With this approach, when a Delphi DLL is dynamically loaded, it
replaces libxml2's memory management functions with its own. That's fine
until the DLL is UNloaded - then the libxml's memory management functions go
with it!


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