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

Ville Vainio vvainio at karhu.tp.spt.fi
Wed Jan 16 05:44:00 EST 2002


Ville Vainio <vvainio at karhu.tp.spt.fi> writes (yes, I'm replying to myself):

> I am trying to create a shared object, which embeds the python
> interpreter.I execute the following:


> ld -b +b/opt/python22/lib/python2.2/lib-dynload demo.o /opt/python22/lib/python2.2/config/libpython2.2.a -o demoso.so
> 
> And get this:
> 
> ld: DP relative code in file /opt/python22/lib/python2.2/config/libpython2.2.a(intobject.o) - shared library must be position
>     independent.  Use +z or +Z to recompile.

Ok, I did some homework (including the little elementary bit about
HP-UX using .sl instead of .so :). Looking at usenet archives, there
seems to be no easy way around. Extracting all the .o's out of
libpython and repackaging them in .sl doesn't work on hpux, because
hpux really seems to require that the objs are compiled
position-independently (unlike linux, or so I read).

So, would I be severely punished for forcing gcc to compile all objs
to -fPIC by putting that option to OPT variable of the ./configure'd
Makefile? Afterwards, I would extreact all the objs w/ ar and
repackage them in a shared library. Does this break any modules? I'm
concerned about xml.dom.minidom (which uses expat) in particular.

I must apologize for flooding the newsgroup with these messages
(frequent posting), but I really need to resolve this issue pretty
quickly.

And yes, I do have to create a shared library. Static linking is not
an option, because I will be using the library from a 4GL.

-- 
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 mailing list