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