Shared libpython, PIC, whinery (was Re: Embedding python in .so, /libpython2.2.a not position independent (hp-ux)??
vvainio at karhu.tp.spt.fi
Fri Jan 18 10:22:50 CET 2002
martin at v.loewis.de (Martin v. Loewis) writes:
> Ville Vainio <vvainio at karhu.tp.spt.fi> writes:
> > own. My question is: why is libpython not built to be position
> > independent in the first place?
> You didn't ask why libpython should not always be built as a shared
> library. I feel that it would be stupid to do so by default: many
Me too; I ended up using the static library, even though I compiled it
> It does: you have to find out how to instruct the compiler to generate
> PIC code. On some systems, it may introduce dependencies on a specific
Well, the ./configure seems to know; Makefile has
CCSHARED = -fPIC. Also, the modules are compiled to PIC.
> > something or whatever. The current approach requires a bit too much
> > hacking to be easily repeatable (by code maintainers etc.).
> It is not intended to be easily repeatable. Embedding Python in this
> specific way is a too-rare application to justify anybody spending
> time into investigating the details (patches are encouraged, of
Yes, perhaps; but as Python gains more popularity, such incidences
become more frequent (I don't think this particular kind of embedding
is all that exotic, nor do I think that it is a futile effort). At
least documenting this thing properly (one sentence in Embedding &
Extending docs, perhaps?) could help some people quite a bit. Even a
simple sentence like "libpython is not compiled to PIC for performance
and portability reasons, but you are free to do so if you think your
platform can handle it" would have made a difference.
Ville Vainio - http://www.tp.spt.fi/~vvainio - ICQ #115524762
Wild geese have no intention to cast a reflection
Water has no mind to assume their form
More information about the Python-list