[Python-Dev] build problems under Solaris

[Greg Ward]

On 28 October 2000, Martin v. Loewis said:
> > I don't have access to a Solaris machine, so I can't do anything to
> > help these users.
> 
> The patch in 117606 looks right to me: gcc on Solaris (and on any
> other platform) needs -shared to build shared library; configure
> currently passes -G. I haven't actually tried the patch, since it is a
> pain to extract it from the SF bug report page. What happens is that
> gcc passes -G to the linker, which correctly produces a shared
> library.  However, gcc also links crt1/crti into the library, which
> causes the reference to main.

Well, I do have access to a Solaris machine -- I try not to use it if I
don't have to, and about the only purpose it has these days is
occasionally building Python to make sure it still works.

Incidentally, I'm the one who changed "ld -G" to "$(CC) -G" -- see
revision 1.124 of configure.in:

  revision 1.124
  date: 2000/05/26 12:22:54;  author: gward;  state: Exp;  lines: +6 -2
  When building on Solaris and the compiler is GCC, use '$(CC) -G' to
  create shared extensions rather than 'ld -G'.  This ensures that shared
  extensions link against libgcc.a, in case there are any functions in the
  GCC runtime not already in the Python core.

I think the checkin message there is fairly clear; the context was in
using Robin Dunn's extension for BSDDB 2.x, which does some 64-bit
arithmetic deep down inside.  Turned out that GCC compiled a 64-bit
divide into a function call, and that function is in GCC's own runtime
library.  Using "ld -G" -- that's Sun's linker, which knows nothing
about GCC's runtime library -- the function in question wasn't
available, so loading the extension failed.  I assume that if *Python*
did a 64-bit divide somewhere in *its* guts, that function would have
been available (linked into the python binary), which is why this
problem doesn't come up very often -- Python probably does use most of
GCC's runtime.  ;-)

Anyways, I thought the patch in bug #117606 looked fine, so I tried it
out.  Not so good; here's what happens when I try to build
arraymodule.so (the first extension, alphabetically) with "gcc -shared":

  Text relocation remains                         referenced
      against symbol                  offset      in file
  _PyObject_NewVar                    0x654       arraymodule.o
  <unknown>                           0x26cc      arraymodule.o
  <unknown>                           0x26c8      arraymodule.o
  [...many many <unknown> symbols...]
  PyErr_Occurred                      0x1274      arraymodule.o
  PyErr_Occurred                      0x4a0       arraymodule.o
  PyErr_Occurred                      0x22d8      arraymodule.o
  PyErr_Occurred                      0x115c      arraymodule.o
  PyErr_Occurred                      0x368       arraymodule.o
  PyErr_Occurred                      0x1074      arraymodule.o
  PyErr_Occurred                      0x1f50      arraymodule.o
  PyInt_FromLong                      0x3f4       arraymodule.o
  [...]
  _Py_NoneStruct                      0x19d4      arraymodule.o
  Py_InitModule4                      0x26b8      arraymodule.o
  ld: fatal: relocations remain against allocatable but non-writable sections
  collect2: ld returned 1 exit status

All told, there were 500+ relocation errors in that one extension.
About half where "Py" or "_Py" symbols; a bunch were "<unknown>", and
the rest were 'malloc', 'memcpy', 'sprintf', and other standard library
functions.  So apparently "-shared" tells GCC to forget everything it
knows about linking C code and be as stupid as it can.  Hmmm.

I tried adding "../libpython2.0.a", and "-L.. -lpython2.0", and instead
got 20,000 relocation errors, since of course libpython2.0.a needs a lot
more symbols than arraymodule.o.  Hmmm.

I have no idea what's going on here.  I've updated the bug report, and I
am definitely -1 on "gcc -shared" for GCC on Solaris!  Unless, of
course, there are other linker options that make it work right...

        Greg