Mark Hollomon <mhh@mindspring.com> writes:
> No. The problem is that the code in python.a is not (necessarily) relocatable.
> And if it isn't, it can't go into a shared library.
>
> Appently GCC on an i86/Elf based Linux platform, compiles _all_ code as
> relocatable. So you can get alway with all kinds of stuff. But at least on
> HPUX, the vendor compiler does not create relocatable objects unless
> specifically asked to do so. And as a rule no-one does unless they are
> creating a shared library.
In the interests of precision, I want to correct your terminology
here.
All files created by a Unix assembler, or by a Unix compiler with the
-c option, are relocatable. That just means that the linker can
relocate them to run at some address chosen at link time.
Many shared library systems use two types of code: normal code and
position independent code (PIC). Of those shared library systems
which use PIC, some require that all code in a shared library be PIC.
Position independent code can run at any address, or more precisely,
in many implementations, at some address chosen at run time just
before the program starts.
(For those shared library systems which use PIC but do not require it,
shared libraries built with PIC are more efficient. I omit the case
of Windows, which uses a primitive system which does not use PIC but
instead requires source code changes to run in a shared library.)
So we have three cases:
1) Shared library system does not use PIC (e.g., SVR3, AIX).
2) Shared library system uses PIC, but does not require it (e.g., ELF systems, including SVR4, Solaris, Linux and
*BSD).
3) Shared library system uses PIC, and requires it (e.g., HP/UX).
When you say that gcc on an ix86/ELF based Linux platform compiles all
code as relocatable, you are correct. But that is a nearly vacuous
statement, as gcc on all platforms compiles all code as relocatable.
You might have intended to say that gcc on an ix86/ELF based Linux
platform compiles all code as PIC. If that is what you meant to say,
you were wrong.
Ian
