RE: [xml] LibXML 2.3.5 (Win32)

[Igor Zlatkovic <izlatkovic daenet de>]

Hello there,

You are trying to do what cannot be done at the moment :-). Seriously, if
you are using GNU compiler, then everything should be fine. If you however
use MS compiler, then the trouble begins.

There is a fact: Under UNIX, all non-static symbols are automagically
exported from a shared library, or so I heard. Under Windows, using MS
compiler, only symbols declared as exportable are exported, and, there is no
way known to me to avoid declaring a symbol as exportable and have it
exported.

Well, nothing in libxml is declared as exportable and the linker ends up
with a DLL which exports no symbols and refuses to build the import library
(.LIB). Isn't that a sad situation? A shared library without exported
symbols... much like a tankard without beer. Useless.

What to do now? Well... read on.

There are two ways to export a symbol in the Microsoft's development
environment:

1. Create a .DEF file and give it to the linker.

A .DEF file does not exist and someone would have to write it. Aditionally,
whenever someone adds a new function, the function name would have to be
added to the EXPORTS section of this file in order to end up exported. Many
people think the whole concept lacks reason somewhat, but it can get much
worse:

2. Declare all symbols with __declspec(dllexport)

When I last looked, there were exactly 13 functions in libxml2 code which
ended up declared as exportable under certain conditions (the
LIBXML_DLL_IMPORT macro). This is certainly not enough, for in order to
export them, all functions would have to be declared this way. Oh, that is
not all. The macro LIBXML_DLL_IMPORT must expand to '__declspec(dllexport)'
only when compiling libxml itself. When compiling something else, like a
program based on libxml, then it must expand either to nothing or to
'__declspec(dllimport)'. If UNIX programmers who read this feel like
vomitting now, go, I shall wait here :-)

You see, there is a certain amount of maintenance involved in keeping libxml
compatible with the Microsoft's development environment. For the time being,
I know of no human willing to do this. Until things change, only static
library can be built from 'win32/libxml2/libxml2_a.dsp' project file.

Cheers
Igor


> -----Original Message-----
> From: Nilo S. Mismetti [mailto:nilo newpos com]
> Sent: Monday, April 09, 2001 2:45 PM
> To: xml gnome org
> Subject: [xml] LibXML 2.3.5 (Win32)
>
>
> Sirs,
>
> I'm trying to compile the Libxml version 2.3.5 for Win32 and:
>
> a) We still receive the following warnings:
>
> HTMLparser.c
> E:\libxmlSrc\HTMLparser.c(1327) : warning C4018: '>=' : 
> signed/unsigned
> mismatch
> E:\libxmlSrc\HTMLparser.c(1328) : warning C4018: '>' : signed/unsigned
> mismatch
> E:\libxmlSrc\HTMLparser.c(1506) : warning C4018: '!=' : 
> signed/unsigned
> mismatch
> parserInternals.c
> E:\libxmlSrc\parserInternals.c(1056) : warning C4018: '>' : 
> signed/unsigned
> mismatch
> xpath.c
> E:\libxmlSrc\xpath.c(6466) : warning C4101: 'cur' : unreferenced local
> variable
> E:\libxmlSrc\xpath.c(6747) : warning C4102: 'eval_predicates' 
> : unreferenced
> label
> xpointer.c
> Generating Code...
> E:\libxmlSrc\xpath.c(168) : warning C4723: potential divide by 0
> E:\libxmlSrc\xpath.c(171) : warning C4723: potential divide by 0
> E:\libxmlSrc\xpath.c(174) : warning C4723: potential divide by 0
> Linking...
>
> b) The compilation, even with those warnings, does not 
> produces the .LIB
> file (that is normally produced on a .DLL compilation.
>
> Help is welcome. We want to migrate from the version 2.2.4 
> but without a
> .LIB we cannot build our application.
>
> Nilo
>
>
> _______________________________________________
> xml mailing list
> xml gnome org
> http://mail.gnome.org/mailman/listinfo/xml