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

[P. Alejandro Lopez-Valencia]

"Martin v. Loewis" <martin at v.loewis.de> escribió en el mensaje
news:m37kn6wzu4.fsf at mira.informatik.hu-berlin.de...
> "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
> > Binutils instead of the native linker and assembler, something *not
> > recommended at all*.
>
> Can you elaborate? gcc -shared works fine on Solaris, and binutils
> also works without problems.

But binary output is not 100% compatible with system libraries. If you
use the native linker and assembler, the code will be compatible. This
has been considered as "God given truth" in the sun-managers list for
more than 10 years (since I first subscribed). The sun-managers list,
btw, is where all admins, hackers and users with root access discuss
Solaris issues.

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

And open a full can of worms. Why hack the linker flags when you can
impose yourself some discipline in your administration tasks and
make life easier in the future? :)

BTW, this advice of yours does apply to the curses modules under
Solaris, as they are compiled as non-PIC code.

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

And still they won't work. As is the case of the curses modules and the
readline modules in 2.1 and 2.2...

> > 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 of the interpreter.
>
> That is the prime reason why I dislike shared libraries in the first
> place - statically linked binaries are much easier to manage; use of
> shared libraries should be restricted to system libraries, IMO.

It depends on your mindset. Shared libraries do save disk space, and
Solaris default installs tend to create too small partitions for
application space. IMO, few people have the guts to do a hot repartition
(actually it should be called "partition stretching" :).