Python-2.2.1, Solaris7, make test fails...

[P. Alejandro Lopez-Valencia]

"Hugh Sasse Staff Elec Eng" <hgs at dmu.ac.uk> escribió en el mensaje
news:mailman.1019036193.29349.python-list at python.org...
On Tue, 16 Apr 2002, P. Alejandro Lopez-Valencia wrote:


On 17 Apr 2002, Martin v. Loewis wrote:

> "P. Alejandro Lopez-Valencia" <dradul at yahoo.com> writes:
>
> > And while you are at it... You have not compiled python itself as
PIC
> > code. No, gcc -shared *doesn't* work in Solaris unless you are using
GNU
        [...]
> Can you elaborate? gcc -shared works fine on Solaris, and binutils
> also works without problems.

>AFAIK this is true.  I've not had problems like this with other
>packages.

As said in other message, this is not the recommended procedure; the
fact
that you can does not mean you should. GNU as does not generate 100%
compatible binary object code, and GNU ld tends to botch Sparc object
code linked against libraries created with Sun tools (that is system
libraries, and you link libc, libnsl and libsocket with almost
everything like it or not).

>
> > Solaris' linker can't build a dynamic loading library/module using
> > object code compiled in position dependent mode.
>
> And rightly so. That should never be a problem, though.
>
> Actually, you *can* talk the Solaris linker to incorporate non-PIC
> text into a shared library. For that, it will make the text segment
> writable. The -mimpure-text option of gcc triggers that feature.

OK, but shouldn't this sort of information be in the configure script?

I don't think so. This part of the lore that makes you a true "Solaris
expert" whatever that may be. I have used Sun boxes for 12 years and
Solaris since it came out ( was that in '94?) and yet, I am no expert at
all :)

But seriously, Solaris is quirky, but no one contributes the appropriate
patches to CVS... (I am not going to, I have other things to worry about
presently).

>
> > This means, that you need to have all external libraries compiled
with
> > the -fPIC flag, even if they are static.
>
> If you link static libraries into Python, I recommend to make the
> modules that use them also static. Then you don't need PIC code for
> those.

Wouldn't this make the memory image of all python programs much larger?
        [...]

Nah. This is misinformed exaggeration. The culprit of unnecessary fluff
is gcc itself, and it becomes worse with each new release. If you are
concerned with executable size, you should add an "-s" flag to the gcc
front-end. This strips all debugging symbol code from the binary object
code. In the case of gcc 3 it can mean a size savings of 60% and even
more.

PIC code is inherently slower, but you won't notice any difference in
speed unless you are still using one of those 12 year old Sparc 1's
(Hell, those where slow even then).

Alejo