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

[Martin v. Löwis]

"P. Alejandro Lopez-Valencia" <dradul at yahoo.com> writes:

> 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).

This is FUD. Software does not "tend to" do things. It either does
them, or it doesn't. Use the version of binutils that is recommended
in the gcc release notes, and all will work just fine.

> > 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?

No. Using -mimpure-text has undesirable side effects, such as making
the text segment writable (which in turn means that the shared library
won't be shared across address spaces).

There is only so much that configure can find out automatically. If
you have a slightly broken system, or one that lacks certain features,
you need to give explicit instructions to your tools.

> 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).

Patches that propose to replace -shared with -G when using gcc will be
rejected, as they are plain wrong. Patches that always add
-mimpure-text will be rejected as the cause performance degradation
for extension modules that don't need relocations in their text
segment.

> > 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?

What are "all python programs"? There is only one Python
executable. 

If you are concerned about the memory consumption of python processes:
Since Solaris uses demand-paged memory, code of extensions won't be
loaded into memory until somebody touches the page that has the code,
which usually won't happen until the module is imported.

> 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.

Of course, debugging information does not contribute a bit to the
in-memory consumption, since the dynamic loader skips the debugging
sections when starting a program.

Regards,
Martin