Shared libpython, PIC, whinery (was Re: Embedding python in .so, /libpython2.2.a not position independent (hp-ux)??

[Ville Vainio]

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

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

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