[ python-Bugs-1557490 ] 2.5c1 Core dump during 64-bit make on Solaris 9 Sparc

SourceForge.net noreply at sourceforge.net
Wed Sep 13 17:50:39 CEST 2006


Bugs item #1557490, was opened at 2006-09-12 17:36
Message generated for change (Comment added) made by tony_bigbee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557490&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Tony Bigbee (tony_bigbee)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.5c1 Core dump during 64-bit make on Solaris 9 Sparc

Initial Comment:
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.




----------------------------------------------------------------------

>Comment By: Tony Bigbee (tony_bigbee)
Date: 2006-09-13 11:50

Message:
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.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-13 01:47

Message:
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557490&group_id=5470


More information about the Python-bugs-list mailing list