[Patches] [ python-Patches-527027 ] Allow building python as shared library

noreply@sourceforge.net noreply@sourceforge.net
Fri, 08 Mar 2002 03:09:16 -0800


Patches item #527027, was opened at 2002-03-07 17:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=527027&group_id=5470

Category: Build
Group: Python 2.2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Ondrej Palkovsky (ondrap)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow building python as shared library

Initial Comment:
This patch allows building python as a shared library. 

 - enables building shared python with
'--enable-shared-python' configuration option
 - builds the file '.so' by default and changes the
name on installation, so it is currently enabled on
linux to be '0.0', but this can be easily changed
 - tested on linux, solaris(gcc), tru64(cc) and HP-UX
11.0(aCC). It produces the library using LDSHARED -o,
while some architectures that were already building
shared, used different algorithm. I'm not sure if it
didn't break them (someone should check DGUX and BeOS).
It also makes building shared library disabled by
default, while these architectures had it enabled.

- it rectifies a small problem on solaris2.8, that
makes double inclusion of thread.o (this produces error
on 'ld' for shared library).


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-08 12:09

Message:
Logged In: YES 
user_id=21627

While I agree on the "not Linux only" and "use standard
configure options" comments; I completely disagree on
libtool - only over my dead body. libtool is broken, and it
is a good thing that Python configure knows the compiler
command line options on its own.

----------------------------------------------------------------------

Comment By: Ondrej Palkovsky (ondrap)
Date: 2002-03-08 11:52

Message:
Logged In: YES 
user_id=88611

Sorry, I've been inspired by the former patch and I have
mistakenly included it here. My patch doesn't use LD_PRELOAD
and creates the .a with -fPIC, so it is compatibile with
other  makes (not only GNU). I'll try to learn libttool and
and try to do it that way though.

----------------------------------------------------------------------

Comment By: Matthias Urlichs (smurf)
Date: 2002-03-08 11:22

Message:
Logged In: YES 
user_id=10327

IMHO this patch has a couple of problems.

The main one is that GNU configure has standard options for enabling shared library support, --enable/disable-shared/static. They should be used!

The other is that it's Linux-only. Shared library support tends to work well, for varying definitions of "well" anyway, on lots of platforms, but you really need to use libtool for it. That would also get rid of the LD_PRELOAD, since that'd be encapsulated by libtool.

It's a rather bigger job to convert something like Python to libtool properly instead of hacking the Makefile a bit, and the build will definitely get somewhat slower as a result, BUT if we agree that a shared Python library is a good idea (i think it is!), the work is definitely worth doing.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-07 19:36

Message:
Logged In: YES 
user_id=21627

As the first issue, I'd like to clarify ownership of this
code. This is the same patch as #497102, AFAICT, but
contributed by a different submitter. So who wrote created
that code originally?

The same comments that I made to #497102 apply to this patch
as well: why 0.0; please no unrelated changes (Hurd); why
create both pic and non-pic objects; please no
compiler-specific flags in the makefile; why LD_PRELOAD.



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-07 18:09

Message:
Logged In: YES 
user_id=6380

Could you submit the thread.o double inclusion patch
separately? It's much less controversial.

I like the idea of building Python as a shared lib, but I'm
hesitant to add more code to an already super complex area
of the configuration and build process.

I need more reviewers. Maybe the submitter can get some
other developers to comment?

P.S. it would be better if you used the current CVS or at
least the final 2.2 release as a basis for your patch.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=527027&group_id=5470