Getting expat compiled properly

[Magnus Lie Hetland]

"Martin von Loewis" <loewis at informatik.hu-berlin.de> wrote in message
news:j4bskomru8.fsf at informatik.hu-berlin.de...
> "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.

Of course. I thought the point was to set it while the program ran
(in CGI), which is not in my shell.

[snip]
> > But it _doesn't_ find a dynamic one... That's why it doesn't work...
>
> It sure did.

Again, not while running, otherwise it would work just fine, wouldn't it?

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

Yes. While compiling. So the way I've understood all this is that setting
the LD_LIBRARY_PATH while _compiling_ is what does the trick, right?

[snip]
> > 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)).

Of course.

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

OK.

[snip]
> > 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).

Oh, well. I'm getting a Linux box here soon. It's just that the
Solaris boxen are centrally managed (with backups etc.) and that's
so comfortable ;)

[snip]
> 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.

OK. That's useful to know... But how do I express that instead of
using -l? Can I use -L? Or?

(Sorry to ask for so many details... Feel free to ignore this posting,
and I'll go look more thoroughly myself. Thanks for your help :)

> 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