[ 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