This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: please update libXML (undefined references)
Rob,
On Mon, Jul 22, 2002 at 05:27:50PM +1000, Robert Collins wrote:
> > -----Original Message-----
> > $ python pytest.py
> > Traceback (most recent call last):
> > File "pytest.py", line 1, in ?
> > import libxml2;
> > File "/usr/lib/python2.2/site-packages/libxml2.py", line 1, in ?
> > import libxml2mod
> > ImportError: No module named libxml2mod
> >
> > $ ls /usr/lib/python2.2/site-packages/
> > README* libxml2.py libxml2mod.a libxml2mod.la*
> > cygxml2mod.dll* libxml2.pyc libxml2mod.dll.a*
> >
> > Libtool names the module 'cygxml2mod.dll' and the common name is
> > 'libxml2mod.dll'.
>
> I've uploaded libxml regardless of this issue. A because the python
> bindings are new, and B because cygfoo.dll is the standard for cygwin
> .dll's. libtool is correct, python incorrect.
Stating that Python is "incorrect" above is a little strong -- I would
prefer "Python does not work that way" instead. Note that if one uses
Distutils (i.e., the recommended way to build Python shared extension in
a platform independent way), then the "right thing" will happen.
AFAICT, under Unix a Python shared extension module called "foo" must be
stored in a file call "foo.${SO}" or foomodule.${SO}". Where "${SO}" is
the shared library extension for that platform (e.g., "so" on Linux,
"dll" on Cygwin, "sl" on HP-UX, etc.). So even under Linux, "libfoo.so"
would generated the same error as the above. For example:
$ ./python -c 'import pwd'
$ mv build/lib.linux-i686-2.3/pwd.so build/lib.linux-i686-2.3/libpwd.so
$ ./python -c 'import pwd'
Traceback (most recent call last):
File "<string>", line 1, in ?
ImportError: No module named pwd
Jason