[Python-bugs-list] [ python-Bugs-589429 ] libpython.a with PIC objects

[noreply@sourceforge.net]

Bugs item #589429, was opened at 2002-08-01 02:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589429&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: libpython.a with PIC objects

Initial Comment:
when configuring with --enable-shared, the "static" 
library libpython.a is build with PIC-compiled objects.
Using the option --enable-shared builds a shared library 
in addition to the static library (with objects compiled 
without PIC).


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

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

Message:
Logged In: YES 
user_id=21627

Ok, this behaviour is now documented in README 1.151.

I still don't understand why you need a non-PIC libpython.a,
and I don't think that the standard build process should
produce a file named libpython_pic.a. My suggestion would be
to just run configure once - I still cannot see what
problems this would cause.

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

Comment By: Matthias Klose (doko)
Date: 2002-08-03 18:23

Message:
Logged In: YES 
user_id=60903

well, why not call this library libpython_pic.a then? Or at
least it should be *documented*, that libpython.a contains
pic objects when configured with --enabled-shared, and
non-pic objects, when configured without --enabled-shared

I currently work around by building python twice: a complete
build without --enable-shared and a second build building
only libpython2.3.so.1.0. The configury is done twice, but I
get what I want.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-03 13:05

Message:
Logged In: YES 
user_id=21627

I personally think that all the other packages are "wrong",
or perhaps address different usage scenarios:

If you have a PIC-compiled static library, you can link this
static library into other DSOs. Not having a PIC-compiled
library causes problems. 

E.g. on Solaris, people building Python extension modules
frequently find that they only have a static version of
libreadline or OpenSSL, which they then cannot integrate
into the readline or socket Python modules (because you need
PIC code for a DSO).

So, a PIC static library can support use cases that a
non-PIC static library cannot. The downside is that the PIC
library might be less efficient. User using --enable-shared
have already accepted less efficient code (since the shared
library is also PIC), so they should accept PIC code in the
static library as well.

In addition, not building non-PIC objects simplifies the
build process: you don't have to compile everything twice,
just because somebody may want non-PIC objects. If somebody
really requires non-PIC objects for reasons I cannot see,
they need to recompile Python separately.

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

Comment By: Matthias Klose (doko)
Date: 2002-08-02 20:24

Message:
Logged In: YES 
user_id=60903

I expect (as mostly known from other GNU libraries on Linux
systems), that I get an additional library with
--enable-shared, not a changed static library.
Currently the option really is
--enable-shared-and-build-static-with-pic.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-02 15:49

Message:
Logged In: YES 
user_id=21627

What is the bug here?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589429&group_id=5470