Getting expat compiled properly

Magnus Lie Hetland mlh at idi.ntnu.no
Wed Sep 5 00:55:54 EDT 2001


"Martin von Loewis" <loewis at informatik.hu-berlin.de> wrote in message
news:j4lmjvme2q.fsf at informatik.hu-berlin.de...
> "Magnus Lie Hetland" <mlh at idi.ntnu.no> writes:
>
> > I have managed to compile expat so it works with
> > Python (2.2a1), but when I try to run cgi scripts now,
> > they don't work. The reason is that Python can't
> > find libexpat.so ...
>
> You didn't mention what operating system you are using;

Ah... Sorry. Solaris. (SunOS 5.8)

> most likely,
> setting LD_LIBRARY_PATH would work around this problem?

The problem is that I'm not an administrator at this machine, so
it would be a bit awkward... I guess I could take the #!/usr/bin/env
trick to new heights, but...

> On Linux,
> adding the path containing libexpat.so into /etc/ld.so.conf would also
> help.

Again not an option.

> > I thought this was supposed to be a static link (with libexpat.a)?
>
> What made you think so? In the presence of both a static and a dynamic
> library, all linkers I know will prefer the dynamic one (unless you
> tell them otherwise).

But it _doesn't_ find a dynamic one... That's why it doesn't work...
And if libexpat were statically linked (as described in the Modules/Setup
files), it shouldn't fret, should it?

> > How am I supposed to do this to make it work properly?
>
> There are many options. I'd recommend to build libexpat as a static
> library only;

I did. I guess there is a dynamic one somewhere else on my machine...
I guess I'll have to edit LD_LIBRARY_PATH when compiling, so it
doesn't find the dynamic one, then. Right?

> if you want pyexpat as a dynamic extension module, make
> sure to build it as PIC code, though.

PIC?

> > I've edited the lines in Modules/Setup -- I can't find any other,
> > more "Distutils-like" way of doing it... Is there something else I'm
> > missing?
>
> If you want to pass a -R option to the linker, that's the proper
> way. It also is the proper way if you want to statically build pyexpat
> into the interpreter.

I tried a couple of ways, but it didn't work...

> > What's going on here? With all the XML support in
> > Python 2.2, installing expat (which is a requisite)
> > really ought to be simple, no?
>
> Why do you think it ought to be simple?

Because there currently is no other way of using the official Python
xml modules. If there were a backend for xml.sax which used
xmllib (and that wasn't deprecated), I wouldn't mind. And if I could
use a ready-built dist (like the windows version) everything would
be just fine...

Oh, well. I guess it is pretty easy under more normal circumstances.

> expat is a project completely
> independent from Python - there is only a slight overlap in the
> contributors to both projects. So "we" (as Python contributors) can do
> nothing but give instructions on how to build libexpat; using those
> instructions, you would have ended up with only a libexpat.a, and no
> libexpat.so.

I did. But, as I said, there is a libexpat.so in the "official" lib
dirs on the machine. (And I'm certainly not blaming anyone for
that... :)

> Regards,
> Martin

--

  Magnus Lie Hetland         http://www.hetland.org

 "Reality is that which, when you stop believing in
  it, doesn't go away."           -- Philip K. Dick






More information about the Python-list mailing list