Re: [xml] Problem building libxml-python on VC++ 6

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

Hi there,

Well... I have never used python and have really no idea what the problem
might be. How can fiddling with a python source file (setup.py) affect the
export table of libxml is a puzzle to me.

Of course, I would have to get familiar with python in order to know what
fares, but I can imagine that this LIBXML_EXPORT macro has its role in all
of it. I don't know what exactly you guys compile to create a python
binding, but obviously there is some C in it. I think that, whatever it is,
it needs an export table which it cannot fully inherit from libxml. If this
is so, an export definition file must be written.

I'll try to steal few hours during the weekend to investigate this matter.
It sounds interresting. If I manage to produce a working python binding on
Windows, I'll have it enter the Windows makefile as a standard feature.
Although I don't know or use python, those few articles I have read say only
the best about the language, so the feature is well worth bothering.

Ciao
Igor


> On Sat, Apr 06, 2002 at 09:25:54AM -0500, Douglas Law wrote:
> > Daniel,
> >
> > I have been compiling and using libxml on a VC++ 6 environments for a
> > while now, and it is great.
> >
> > I now have a need to use python for some of our XML work and have
> > attempted to build the libxml-python interface (using thre source
> > release 2.4.19).  Initially I was getting unresolved reference errors
> > during the link stage for all of the libxml functions.  After fiddling
> > with the LIBS setting in the setup.py script I have gotten rid of the
> > errors except those dealing with memory allocation.
>
>   Hum, you're probably the first one to try to build the python bindings
> on Windows (well that's the first report I got).
>
> > Specifically, I get 4 unrsolved references for libxml.obj:
> >   _xmlMemAlloc
> >  _xmlMemoryStrDup
> > _xmlMemRealloc
> > _xmlMemFree
> >
> > I'm sure this is a stupid mistake as I am a newbee at building open
> > source stuff.
>
>   And I'm a complete newbie when it comes to Windows DLL/OBJ
specificities,
> maybe Igor could explain where the problem may be.
>
> > Any pointers you have would be greatly appreciated (including whether or
> > not this was the write place to ask this type of question .. I did try
> > to find the answer in the other recommended places first.)
>
>   Could it be that those interfaces are not exposed as "exported"
> from the Windows library and hence generate linking error contrary to
> others symbols ?