Issue 1557490: 2.5c1 Core dump during 64-bit make on Solaris 9 Sparc (original) (raw)

Created on 2006-09-12 21:36 by tony_bigbee, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (5)
msg60997 - (view)	Author: Tony Bigbee (tony_bigbee)	Date: 2006-09-12 21:36
Building with gcc 4.1.1 SunOS 5.9 sun4u sparc SUNW,Sun-Fire-V490 LDFLAGS=-mcpu=v9 -m64 LDDFLAGS=-mcpu=v9 -m64 -G CC=gcc -mcpu=v9 -m64 -D_LARGEFILE64_SOURCE=1 ./configure --prefix=/projects/python make (many successful .c files omittted) gcc -mcpu .... Parser/pgenmain.o -lresolv -lsocket -lnsl -lrt -ldl -o Parser/pgen Parser/pgen ./Grammar/grammar ./Include/graminit.h ./Python/graminit.c *** Signal 11 -core dumped (ignored) compiling and linking continues until the new python executable is invoked to run setup.py and that fails. I previously built 2.5c1 without all the compile/link flags above as a vanilla 32-bit app without a problem. LD_LIBRARY=/usr/ccs/lib/:/usr/lib:/usr/local/lib the python executable will not start with any command line option.
msg60998 - (view)	Author: Neal Norwitz (nnorwitz) *	Date: 2006-09-13 05:47
Logged In: YES user_id=33168 I was able to build with gcc 4.0.2 on Solaris sun4u system with the same flags as above. ./python: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped However, it couldn't build the extension modules because: ld.so.1: python: fatal: libgcc_s.so.1: open failed: No such file or directory That's a different problem though. The interpreter itself is just fine. You might want to try lowering the optimization level to -O1 or -O0 and see if you have the same problem. Or you could try building with a different C compiler.
msg60999 - (view)	Author: Tony Bigbee (tony_bigbee)	Date: 2006-09-13 15:50
Logged In: YES user_id=1478976 I have confirmed that gcc 3.4.2 also successfully builds an ELF 64-bit for 2.5c2 and the interpreter works. Putting the sparcv9 64-bit shared libraries first in LD_LIBRARY_PATH also fixes the extension building problem nnorwitz noted. Only a few extension modules fail to build (per the 2.5 Release Candidate 2 news item) because of dependence of 32-bit ELF class .sos: _tkinter (libtk8.4.so, libtcl8.4.so) _sqlite3 (libsqlite3.so) _ssl ((libcrypto.a(digest.o)) _hashlib (libcrypto.a(digest.o)) bz2 (libbz2.a(bzlib.o)) But this might be fixed by recompiling these libraries as 64-bit. LD_LIBRARY_PATH=/usr/lib/sparcv9:/usr/local/lib/sparcv9: ... Will report back results attempting 4.0.2 and LD_LIBRARY_PATH modification to see if extension modules can be built to mirror 3.4.2 results.
msg61000 - (view)	Author: Martin v. Löwis (loewis) *	Date: 2006-09-16 17:33
Logged In: YES user_id=21627 If this is indeed compiler-dependent, it will be very difficult to analyse: it could be a compiler bug (i.e. the compiler generating bad code), or it could be a Python bug (the Python C code not being fully portable or correct).
msg84472 - (view)	Author: Daniel Diniz (ajaksu2) *	Date: 2009-03-30 03:08
Rejecting this on lack of feedback, likelihood of being a compiler problem and being solvable by a different order of 64bit libraries in LD_LIBRARY_PATH.