Getting expat compiled properly

[Martin von Loewis]

"Magnus Lie Hetland" <mlh at idi.ntnu.no> writes:

> > 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...

You can certainly set LD_LIBRARY_PATH in your shell.

> > > 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...

It sure did. ld(1) did find the library, otherwise, pyexpat.so would
not refer to the shared library.

> And if libexpat were statically linked (as described in the Modules/Setup
> files), it shouldn't fret, should it?

That should work, yes.


> > 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...

It can't be just "somewhere"; it must be in one of the paths passed as
-L options when linking pyexpat.so (including the paths specified in
certain environment variables, see ld(1)).

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

Position-independent code, specified through -KPIC or -fPIC, depending
on the compiler. This is mandatory for object files that get
integrated into a shared library.

> 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.

If you want simplicity, you shouldn't be using Solaris :-) They don't
even have a convenient mechanism for globally adding directories to
the ld.so.1 search path (no, crle(1) is not convenient).

> 
> > 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... :)

I see (I did not take your previous statement that there might be a
libexpat.so somewhere for definite). In that case, specifying the full
libexpat.a path to the linker (instead of using a -l option) will do
the trick.

Regards,
Martin