Mailing List Archive

Nick Belshaw writes:
>Whilst trying to get Python plugins to work on Gnumeric-0.23 I bumped up
>against the need for libpython1.5.so.0.0.0

Python doesn't build a .so file, so I think the Gnumeric
people must have hacked Python to build one; you may want to check
with them and see if they have build instructions or an RPM available.
Alternatively, you can make a shareable libpython by setting the
CFLAGS environment variable to "-fPIC" before running ./configure and
compiling Python. Then, turn libpython.a into libpython.so with "gcc
-shared -o libpython.so libpython.a" (the exact command may require
some tweaking), and copy libpython.so to wherever you like.

--
A.M. Kuchling http://starship.python.net/crew/amk/
I think he expected me to agree enthusiastically, but I didn't. Nor did I
contradict him; I have had too much experience of life to attempt to tell a
really rich person anything.
-- Robertson Davies, _The Rebel Angels_

"Andrew M. Kuchling" wrote:

> Nick Belshaw writes:
> >Whilst trying to get Python plugins to work on Gnumeric-0.23 I bumped up
> >against the need for libpython1.5.so.0.0.0
>
> Python doesn't build a .so file, so I think the Gnumeric

Is there any reason it doesn't? It is stunningly useful when building arbitrary
extensions
as you can build them shared and not have to relink python. Or am I
misunderstanding
something?

The last time I built the pykde stuff for FreeBSD I ran into this and ended up
hacking
together a libpython1.5.so which solved all my linking problems.


--
Cheers,
david davidh@progmatics.com.au

Progmatics Pty Ltd - Architects of IT and Internet Solutions

Level 8, 191 Clarence Street Phone +61 2 9262 4933
Sydney NSW Australia Fax +61 2 9262 4045
http://www.progmatics.com.au/

Nick Belshaw writes:
> Whilst trying to get Python plugins to work on Gnumeric-0.23 I bumped up
> against the need for libpython1.5.so.0.0.0

Here's a patch to the top-level Makefile.in which adds a "shared"
target. Can people please try this and see if it works on your
favorite Unix variant? It doesn't verify that you've compiled all the
code with -fPIC or whatever's required; I'm not sure how to check or
enforce that. (It could do "make clean ; make CCFLAGS=<whatever>",
but is that too extreme?)

Index: Makefile.in
===================================================================
RCS file: /projects/cvsroot/python/dist/src/Makefile.in,v
retrieving revision 1.80
diff -C2 -r1.80 Makefile.in
*** Makefile.in 1999/02/23 15:43:15 1.80
--- Makefile.in 1999/04/19 00:53:28
***************
*** 214,217 ****
--- 214,226 ----
libtool -o $(LDLIBRARY) -dynamic $(OTHER_LIBTOOL_OPT) $(LIBRARY) -framework System @LIBTOOL_CRUFT@

+ # Target to make a shared library containing the interpreter
+
+ shared: $(LIBRARY)
+ test -d .shared || mkdir .shared ; \
+ (cd .shared;ar x ../$(LIBRARY); $(LDSHARED) -o ../libpython$(VERSION).$(SO) *.o ); \
+ /bin/rm -rf ./.shared
+
+
+
$(SUBDIRS): Makefiles


--
A.M. Kuchling http://starship.python.net/crew/amk/
Since I killed my son... the Dreaming has not been the same ... or perhaps I
was no longer the same. I still had my obligations... But even the freedom of
the Dreaming can be a cage, of a kind, my sister.
-- Dream, in SANDMAN #69: "The Kindly Ones:13"

"A.M. Kuchling" <amk1@erols.com> writes:
> Nick Belshaw writes:
> > Whilst trying to get Python plugins to work on Gnumeric-0.23 I bumped up
> > against the need for libpython1.5.so.0.0.0
>
> Here's a patch to the top-level Makefile.in which adds a "shared"
> target. Can people please try this and see if it works on your
> favorite Unix variant?

It works on mine (bog standard redhat5.2/i686 glibc2 egcs 1.1.2) and
now gnumeric loads Python extensions! Yippee!

I had to make a small change to the patch, see below.

> It doesn't verify that you've compiled all the
> code with -fPIC or whatever's required; I'm not sure how to check or
> enforce that. (It could do "make clean ; make CCFLAGS=<whatever>",
> but is that too extreme?)

The proper answer is to use libtool I suppose. You need to build with
"make OPT='-g -O2 -fPIC'" rather then CCFLAGS, btw.

> Index: Makefile.in
> ===================================================================
> RCS file: /projects/cvsroot/python/dist/src/Makefile.in,v
> retrieving revision 1.80
> diff -C2 -r1.80 Makefile.in
> *** Makefile.in 1999/02/23 15:43:15 1.80
> --- Makefile.in 1999/04/19 00:53:28
> ***************
> *** 214,217 ****
> --- 214,226 ----
> libtool -o $(LDLIBRARY) -dynamic $(OTHER_LIBTOOL_OPT) $(LIBRARY) -framework System @LIBTOOL_CRUFT@
>
> + # Target to make a shared library containing the interpreter
> +
> + shared: $(LIBRARY)
> + test -d .shared || mkdir .shared ; \
> + (cd .shared;ar x ../$(LIBRARY); $(LDSHARED) -o ../libpython$(VERSION).$(SO) *.o ); \

-----------------------------------------------------------------------------^

This period shouldn't be here.

> + /bin/rm -rf ./.shared
> +
> +
> +
> $(SUBDIRS): Makefiles
>
>
> --
> A.M. Kuchling http://starship.python.net/crew/amk/
> Since I killed my son... the Dreaming has not been the same ... or perhaps I
> was no longer the same. I still had my obligations... But even the freedom of
> the Dreaming can be a cage, of a kind, my sister.
> -- Dream, in SANDMAN #69: "The Kindly Ones:13"

Thanks a lot!

Michael

A.M. Kuchling writes:
> Here's a patch to the top-level Makefile.in which adds a "shared"
> target. Can people please try this and see if it works on your
> favorite Unix variant?

I tried this on Linux 2.2.5 with GCC, on Solaris 5.5.1 with the Sun C
compiler (SC4.0 18 Oct 1995 C 4.0) and on Irix 5.3 with the SGI
compiler. Good news is that it works on all of those platforms.
Minor bug is that the generated library is called, on all 3 platforms,
libpython1.5..so (with an extra "." in there)