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

[Hugh Sasse Staff Elec Eng]

On Tue, 16 Apr 2002, P. Alejandro Lopez-Valencia wrote:

>
> "Martin v. Löwis" <loewis at informatik.hu-berlin.de> escribió en el
> mensaje news:j43cxwm1o4.fsf at informatik.hu-berlin.de...
> > Hugh Sasse Staff Elec Eng <hgs at dmu.ac.uk> writes:
> >
> > > > But this is really strange; mathmodule.so must have imported at
> some
> > > > point, or setup.py would have deleted it...
> > >
> > > Hmm.  I don't know.  Anyway, here is the result of re-making the
> > > Python, but not the make test, after removing that file...
> > >
> > > Script started on Mon Apr 15 13:57:01 2002
> > > neelix hgs 1 %> gmake
> > > gcc -shared  Modules/mathmodule.o   -o Modules/mathmodule.so
> >
> > That explains it: he has enabled mathmodule.c in the *shared* section
> > of Setup.

<quote from my Modules/Setup file>
posix posixmodule.c		# posix (UNIX) system calls
_sre _sre.c			# Fredrik Lundh's new regular expressions
new newmodule.c			# Tommy Burnette's 'new' module

# The rest of the modules listed in this file are all commented out by
# default.  Usually they can be detected and built as dynamically
# loaded modules by the new setup.py script added in Python 2.1.  If

    "Usually".  I wanted to be sure they could be, so I enabled them

# you're on a platform that doesn't support dynamic loading, want to

    Given the comments below, this is still the right thing to do, isn't it?

# compile modules statically into the Python binary, or need to
# specify some odd set of compiler switches, you can uncomment the
# appropriate lines below.

    I suggest that this paragraph be re-written to reflect what is
    recommeneded, and the consequences of other choices.

# ======================================================================
        [...]

# Uncommenting the following line tells makesetup that all following
# modules are to be built as shared libraries (see above for more
# detail; also note that *static* reverses this effect):

*shared*
        [...]

# Modules that should always be present (non UNIX dependent):

array arraymodule.c	# array objects
cmath cmathmodule.c # -lm # complex math library functions
math mathmodule.c # -lm # math library functions, e.g. sin()
        [...]
# SunOS specific modules -- off by default:

sunaudiodev sunaudiodev.c
</qoute>

> >
> > I recommend to build Python from original sources, in a fresh
> > directory.

Lots of times, already.  The problem is the correct way to do it.
>
> 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
> Binutils instead of the native linker and assembler, something *not
> recommended at all*. Solaris' linker can't bild a dynamic loading
> library/module using object code compiled in position dependent mode.

I ran configure.  I have tried running configure with --enable-gnu-ld
and this didn't help, even with the latest binutils, so I have used the
sun ld.

>
> This means, that you need to have all external libraries compiled with
> the -fPIC flag, even if they are static. Ahh! And make sure that you
> give the linker the actual library paths you use with an -R flag, else
> the dynamic loader won't find them and you'll have to use an explicit
> LD_LIBRARY_PATH environment variable for each invocation invocation of
> the internpreter.
>
/progs/workshop5/SUNWspro/lib:/ansys50/SC2.0.1:/usr/openwin/lib:/opt/panorama/lib

That could be out of date.  I'll check that...
> --
> http://mail.python.org/mailman/listinfo/python-list
>

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.
>
> > Solaris' linker can't bild 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?
>
> > 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?
        [...]
>
> Regards,
> Martin
> --
> http://mail.python.org/mailman/listinfo/python-list
>
        Hugh