[Python-Dev] more Solaris extension grief

[Martin v. Loewis]

gcc -shared  ./PyEnforcer.o  -L/home/gvwilson/cozumel/merlot/enforcer
-lenforcer -lopenssl -lstdc++  -o ./PyEnforcer.so

> Text relocation remains                         referenced
>    against symbol                  offset      in file
> istream type_info function          0x1c
> /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/libstdc++.a(strstream.o)
> istream type_info function          0x18

> Has anyone seen this problem before?

Yes, there have been a number of SF bug reports on that, and proposals
to fix that. It's partly a policy issue, but I believe all these
patches have been wrong, as the problem is not in Python.

When you build a shared library, it ought to be
position-independent. If it is not, the linker will need to put
relocation instructions into the text segment, which means that the
text segment has to be writable. In turn, the text of the shared
library will not be demand-paged anymore, but copied into main memory
when the shared library is loaded. Therefore, gcc asks ld to issue an
error if non-PIC code is integrated into a shared object.

To have the compiler emit position-independent code, you need to pass
the -fPIC option when producing object files. You not only need to do
that for your own object files, but for the object files of all the
static libraries you are linking with. In your case, the static
library is libstdc++.a.

Please note that linking libstdc++.a statically not only means that
you lose position-independence; it also means that you end up with a
copy of libstdc++.a in each extension module that you link with it.
In turn, global objects defined in the library may be constructed
twice (I believe).

There are a number of solutions:

a) Build libstdc++ as a  shared library. This is done on Linux, so
   you don't get the error on Linux.

b) Build libstdc++.a using -fPIC. The gcc build process does not
   support such a configuration, so you'ld need to arrange that
   yourself.

c) Pass the -mimpure-text option to gcc when linking. That will make
   the text segment writable, and silence the linker.

There was one proposal that looks like it would work, but doesn't:

d) Instead of linking with -shared, link with -G. That forgets to link
   the shared library startup files (crtbeginS/crtendS) into the shared
   library, which in turn means that constructors of global objects will
   fail to work; it also does a number of other things incorrect.

Regards,
Martin