This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Python 2.5b2 fails to build on Solaris 10 (GCC Compiler)
Type: Stage:
Components: Build Versions: Python 2.5
process
Status: closed Resolution:
Dependencies: Superseder:
Assigned To: theller Nosy List: jprante, nnorwitz, ostkamp, theller
Priority: normal Keywords:

Created on 2006-07-26 21:17 by ostkamp, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
typescript_gcc.txt.bz2 ostkamp, 2006-07-26 21:17 build logfiles for Python 2.5b2 with GCC on Solaris 10 (Sparc)
typescript_pydebug.txt.bz2 ostkamp, 2006-07-28 11:28 Build log with --with-pydebug
Messages (8)
msg29299 - (view) Author: Guido Ostkamp (ostkamp) Date: 2006-07-26 21:17
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
msg29300 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2006-07-27 03:21
Logged In: YES 
user_id=33168

Thomas can you check out the ctypes problems?
msg29301 - (view) Author: Thomas Heller (theller) * (Python committer) Date: 2006-07-27 17:23
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?
msg29302 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2006-07-28 04:53
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?
msg29303 - (view) Author: Guido Ostkamp (ostkamp) Date: 2006-07-28 11:28
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
msg29304 - (view) Author: Thomas Heller (theller) * (Python committer) Date: 2006-08-04 19:04
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 .
msg29305 - (view) Author: Thomas Heller (theller) * (Python committer) Date: 2007-07-13 17:54
Clsosing because no response.
msg79057 - (view) Author: Jörg Prante (jprante) Date: 2009-01-04 14:00
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.
History
Date User Action Args
2022-04-11 14:56:19adminsetgithub: 43726
2009-01-04 14:00:08jprantesetnosy: + jprante
messages: + msg79057
2006-07-26 21:17:06ostkampcreate