Python 2.5b2 fails to build on Solaris 10 (GCC Compiler)

[ostkamp]

BPO	1529269
Nosy	@theller
Files	typescript_gcc.txt.bz2: build logfiles for Python 2.5b2 with GCC on Solaris 10 (Sparc) typescript_pydebug.txt.bz2: Build log with --with-pydebug

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/theller'
closed_at = <Date 2009-01-04.14:00:08.432>
created_at = <Date 2006-07-26.21:17:06.000>
labels = ['build']
title = 'Python 2.5b2 fails to build on Solaris 10 (GCC Compiler)'
updated_at = <Date 2009-01-04.14:00:08.432>
user = 'https://bugs.python.org/ostkamp'

bugs.python.org fields:

activity = <Date 2009-01-04.14:00:08.432>
actor = 'jprante'
assignee = 'theller'
closed = True
closed_date = None
closer = None
components = ['Build']
creation = <Date 2006-07-26.21:17:06.000>
creator = 'ostkamp'
dependencies = []
files = ['2079', '2080']
hgrepos = []
issue_num = 1529269
keywords = []
message_count = 8.0
messages = ['29299', '29300', '29301', '29302', '29303', '29304', '29305', '79057']
nosy_count = 4.0
nosy_names = ['nnorwitz', 'theller', 'ostkamp', 'jprante']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1529269'
versions = ['Python 2.5']

[ostkamp]

Hello,

as promised here is the second report because of
problems with building Python 2.5b2 on Solaris 10
(Sparc). I have been using the GCC this time.

These are the problems (for full logs please see
attachments):

building '_ctypes' extension
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_ctypes/_ctypes.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/
Modules/_ctypes/callbacks.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Pyth
on-2.5b2/Modules/_ctypes/callproc.o
build/temp.solaris-2.10-sun4us-2.5/home/ostk
amp/Python-2.5b2/Modules/_ctypes/stgdict.o
build/temp.solaris-2.10-sun4us-2.5/ho
me/ostkamp/Python-2.5b2/Modules/_ctypes/cfield.o
build/temp.solaris-2.10-sun4us-
2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/malloc_closure.o
build/temp.solari
s-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/prep_cif.
o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/l
ibffi/src/sparc/ffi.o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5
b2/Modules/_ctypes/libffi/src/sparc/v8.o
build/temp.solaris-2.10-sun4us-2.5/home
/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v9.o
-o build/lib.solaris
-2.10-sun4us-2.5/_ctypes.so
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeedcca5 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeedccab is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeedccaf is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeedccb3 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeeeae06 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file
build/temp.solaris-2.10-sun4us-2.5
/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o:
symbol <unknow
n>: offset 0xfeeecaf6 is non-aligned
collect2: ld returned 1 exit status

building '_curses' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I/
home/ostkamp/Python-2.5b2/./Include -I./Include -I.
-I/home/ostkamp/Python-2.5b2
/Include -I/home/ostkamp/Python-2.5b2 -c
/home/ostkamp/Python-2.5b2/Modules/_cur
sesmodule.c -o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modu
les/_cursesmodule.o
/home/ostkamp/Python-2.5b2/Modules/_cursesmodule.c: In
function PyCursesWindow_ GetStr': /home/ostkamp/Python-2.5b2/Modules/_cursesmodule.c:822: warning: implicit declar ation of function mvwgetnstr'
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_cursesmodule.o -lcurses -ltermcap -o
build/lib.solaris-2.10-sun4us-2.5/_curses
.so
*** WARNING: renaming "_curses" since importing it
failed: ld.so.1: python: fata
l: relocation error: file
build/lib.solaris-2.10-sun4us-2.5/_curses.so: symbol m
vwgetnstr: referenced symbol not found
building '_curses_panel' extension
gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I/
home/ostkamp/Python-2.5b2/./Include -I./Include -I.
-I/home/ostkamp/Python-2.5b2
/Include -I/home/ostkamp/Python-2.5b2 -c
/home/ostkamp/Python-2.5b2/Modules/_cur
ses_panel.c -o
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modu
les/_curses_panel.o
gcc -shared
build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules
/_curses_panel.o -lpanel -lcurses -ltermcap -o
build/lib.solaris-2.10-sun4us-2.5
/_curses_panel.so
*** WARNING: renaming "_curses_panel" since importing
it failed: No module named
_curses
running build_scripts

Regards,

Guido

[nnorwitz]

Logged In: YES
user_id=33168

Thomas can you check out the ctypes problems?

[theller]

Logged In: YES
user_id=11105

I don't have access to a solaris 10 box myself (only the
sourceforge solaris 9 sparc machine). I'm wondering why the
solaris 10 machine running the Python buildbot does not
report any problems, could it be that this is because it run
configure with '--with-pydebug' ?

Guido, can you please try this?

[nnorwitz]

Logged In: YES
user_id=33168

Hmmm, I thought this was the report from using sun studio
compiler. Guido, are you sure you did a make clean in
between using different compilers?

[ostkamp]

Logged In: YES
user_id=1028306

@theller:
I have tried --with-pydebug, but it gives the same errors.
Please find logfile attached.

@nnorwitz:
I remove the Python-2.5b2 directory and execute a fresh
untar, configure etc. for each try. So there is no
interference with results from different compilers.

In case it matters, I checked for the GCC version used. I
think it came with the Solaris distribution and does use the
system-ld, not gnu-ld (see below for config output):

$ gcc -v 
Reading specs from
/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs
Configured with:
/gates/sfw10/builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure
--prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as
--with-ld=/usr/ccs/bin/ld --without-gnu-ld
--enable-languages=c,c++ --enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)

This is from package

$ pkginfo -l SUNWgcc
   PKGINST:  SUNWgcc
      NAME:  gcc - The GNU C compiler
  CATEGORY:  system
      ARCH:  sparc
   VERSION:  11.10.0,REV=2005.01.08.05.16
   BASEDIR:  /
    VENDOR:  Sun Microsystems, Inc.
      DESC:  GNU C - The GNU C compiler 3.4.3
    PSTAMP:  sfw1020050108051924
  INSTDATE:  Mar 20 2006 14:30
   HOTLINE:  Please contact your local service provider
    STATUS:  completely installed
     FILES:      296 installed pathnames
                   6 shared pathnames
                   5 linked files
                  25 directories
                  33 executables
              104325 blocks used (approx)

Regards,

Guido

[theller]

Logged In: YES
user_id=11105

Guido, in SVN revision 51113 a change was committed that
adds the '-mimpure-text' flag to the linker when linking the
_ctypes.so file. This fixed the build on solaris x86 (there
were relocation errors before).

Can you try if that helps in your case? Thanks.

See also http://python.org/sf/1530448 .

[theller]

Clsosing because no response.

[jprante]

Modules/_ctypes/libffi/src/sparc/v8.S and
Modules/_ctypes/libffi/src/sparc/v9.S are SPARC assembler codes.

The python build process seems to pass the gcc compile flags to compile
these assembler source files.

It makes no sense if the debugging option -g is enabled, because C
source debugging code can not be generated in the case of assembler
code. The Solaris linker is also confused about this and might send the
relocation / alignment errors later.

So, as a workaround, just do not pass the gcc "-g" option to the python
build process when building with Solaris / gcc.

A clean solution would be to avoid gcc C compiler options being passed
to assembler source compiling in the python build process.