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.

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.

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.

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).

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.