build problems under Solaris

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. 117508 looks like a user error to me. On its own, configure would not try to link -ldb, unless it detects the presence of db.h. My guess is that there is a libdb in /usr/local, so a gcc configure finds it, whereas the native compiler doesn't. Later, the linker even finds a -ldb library, but somehow this doesn't have dbopen. So it could be that the BSDDB installation on that system is screwed. Regards, Martin

On 28 October 2000, Martin v. Loewis said:
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

On 28 October 2000, Martin v. Loewis said:
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
participants (2)
-
Greg Ward
-
Martin v. Loewis