Bugs item #1306253, was opened at 2005-09-27 21:10
Message generated for change (Comment added) made by jestone
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306253&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: John Stone (jestone)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.4.2c1 fails to build on 64-bit Solaris 10
Initial Comment:
I have not yet succeeded in compiling Python 2.4.2c1 in
64-bit mode on Solaris 10. I used the following flags
and configuration options, which are the same as what I
used on S9, except for the addition of the
"-xc99=%none" flag to prevent compilation failures due
to some of the other changes from S9 to S10:
setenv CC cc
setenv CXX CC
setenv BASECFLAGS "-native -xc99=%none -xarch=native64
-mt -xO3"
setenv LDFLAGS "-xarch=native64"
./configure --without-gcc
At build time I get these errors:
% make
cc -c -native -xc99=%none -xarch=native64 -mt -xO3
-DNDEBUG -O -I. -I../Include -DPy_BUILD_CORE -o
Modules/python.o ../Modules/python.c
"/usr/include/limits.h", line 290: invalid type combination
"/usr/include/limits.h", line 290: warning: useless
declaration
"/usr/include/limits.h", line 290: warning: typedef
declares no type name
"/usr/include/stdio.h", line 146: warning: useless
declaration
"/usr/include/stdio.h", line 146: warning: typedef
declares no type name
"/usr/include/sys/types.h", line 344: warning:
modification of typedef with "int" ignored
"/usr/include/sys/types.h", line 344: invalid type
combination
"/usr/include/sys/types.h", line 344: warning: useless
declaration
"/usr/include/sys/types.h", line 344: warning: typedef
declares no type name
"/usr/include/sys/types.h", line 484: invalid type
combination
"/usr/include/sys/types.h", line 484: warning: useless
declaration
"/usr/include/sys/types.h", line 484: warning: typedef
declares no type name
"../Include/pyport.h", line 612: #error: "LONG_BIT
definition appears wrong for platform (bad gcc/glibc
config?)."
cc: acomp failed for ../Modules/python.c
*** Error code 2
make: Fatal error: Command failed for target
`Modules/python.o'
----------------------------------------------------------------------
>Comment By: John Stone (jestone)
Date: 2005-09-29 19:42
Message:
Logged In: YES
user_id=48806
The distutils patch you provided definitely cures the build
problems I encountered when using the -xc99=%none compiler
flag, so that at least gives one way to build. Your patch
plus these options built fine (skipped C++ thus far)
setenv CC "cc -xc99=%none -xarch=native64"
./configure --without-cxx
I'll attach the pyconfig.h etc for this combination and I
can send you the same info without those flags if you like.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2005-09-29 18:36
Message:
Logged In: YES
user_id=21627
Can you please attach the generated pyconfig.h? Also, if
possible, can you please attache the preprocessor output of
cc -E -native -xc99=%none -xarch=native64 -mt -xO3
-DNDEBUG -O -I. -I../Include -DPy_BUILD_CORE ../Modules/python.c
As for disabling C99: Python should be perfectly compatible
with C99, and the most recent POSIX release. So there is no
need to disable this. pyconfig.h should set _XOPEN_SOURCE to
600, requesting POSIX 2003. In turn, in line 269 for
feature_tests.h, _XPG6 should be defined, and the #error
should not occur. Can you please investigate why it still does?
As for the distutils bug you are seeing: It comes from the
%none being treated as a format argument. Please try the
attached patch.
----------------------------------------------------------------------
Comment By: John Stone (jestone)
Date: 2005-09-29 16:35
Message:
Logged In: YES
user_id=48806
It isn't an OS bug because that specific problem is caused
by something generated by the autoconf scripts and/or Python
headers, and it's that specific interaction that's causing
the errors. Here's line 290 of /usr/include/limits.h:
typedef unsigned long size_t; /* size of something in bytes */
I suspect there's some bogus line in one of the autoconf
generated includes that's typedefing size_t for itself when
"--without-gcc" is used. I've compiled a few hundred
thousand lines of code in 64-bit mode (some of which do
indeed include limits.h) and not run into this problem prior
to building Python. Since we've determined that the use of
the "--without-gcc" breaks the 64-bit builds universally,
I'm not inclined to dig much deeper on that particular
problem. Removing --without-gcc from the configure options
eliminates that compile problem, leaving the other issues I
mention with the last part of the build process. Regarding
"-xc99=%none", this is now required when building codes that
are pre-POSIX 2003 on Solaris, otherwise the new S10 headers
give you errors:
"/usr/include/sys/feature_tests.h", line 332: #error:
"Compiler or options invalid for pre-UNIX 03 X/Open
applications and pre-2001 POSIX applications"
The comments in the system header pertaning to this say the
following:
/*
* It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5
application
* using c99. The same is true for POSIX.1-1990,
POSIX.2-1992, POSIX.1b,
* and POSIX.1c applications. Likewise, it is invalid to
compile an XPG6
* or a POSIX.1-2001 application with anything other than a
c99 or later
* compiler. Therefore, we force an error in both cases.
*/
In any case, adding -xc99=%none disables the c99 extensions
which conflict with the old POSIX standards. This probably
has to do
with language changes that occured in c99 that may be
incompatible with the oldest POSIX APIs. (elimination of
default type promotion to int perhaps?)
I agree that it's annoying, but that's the way the new
headers work, and many other packages have already updated
their build flags to cope.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2005-09-29 16:08
Message:
Logged In: YES
user_id=21627
If I see a message
"/usr/include/limits.h", line 290: invalid type combination
"/usr/include/limits.h", line 290: warning: useless
declaration
then I'm certain that this is an OS bug. The system compiler
reports an error in the system headers! how could this not
be an OS bug?
What is line 290 of limits.h, anyway?
I don't know what -xc99=%none does, but it looks suspicious:
such a thing should not be necessary to do.
----------------------------------------------------------------------
Comment By: John Stone (jestone)
Date: 2005-09-29 15:46
Message:
Logged In: YES
user_id=48806
It's not an OS bug, it seems certain to be a build system
bug in Python,
please read on.
I did some more digging, and it appears that I can avoid
this problem by removing the "--without-gcc" flag to
configure. This flag is somehow interfering with the build
process. If I remove that flag and instead do the build
like this, I get much farther:
setenv CC "cc -xc99=%none -xarch=native64"
./configure
>From there, I run make and the build proceeds much much
farther successfully linking the python interpreter itself,
but ultimately fails just past that when using the
interpreter to do the rest:
ranlib libpython2.4.a
cc -xc99=%none -xarch=native64 -o python Modules/python.o
libpython2.4.a -lresolv -lsocket -lnsl -lrt
-ldl -lm
case $MAKEFLAGS in *-s*) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc
-xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python
-E ./setup.py -q build;; *) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc
-xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python
-E ./setup.py build;; esac
running build
running build_ext
db.h: found (4, 2) in /usr/local/include
db lib: using (4, 2) db-4.2
INFO: Can't locate Tcl/Tk libs and/or headers
building 'struct' extension
creating build
creating build/temp.solaris-2.10-sun4u-2.4
Traceback (most recent call last):
File "./setup.py", line 1184, in ?
main()
File "./setup.py", line 1178, in main
scripts = ['Tools/scripts/pydoc', 'Tools/scripts/idle',
File "/tmp/Python-2.4.2c1/Lib/distutils/core.py", line
149, in setup
dist.run_commands()
File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line
946, in run_commands
self.run_command(cmd)
File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line
966, in run_command
cmd_obj.run()
File "/tmp/Python-2.4.2c1/Lib/distutils/command/build.py",
line 112, in run
self.run_command(cmd_name)
File "/tmp/Python-2.4.2c1/Lib/distutils/cmd.py", line 333,
in run_command
self.distribution.run_command(command)
File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line
966, in run_command
cmd_obj.run()
File
"/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py",
line 279, in run
self.build_extensions()
File "./setup.py", line 178, in build_extensions
build_ext.build_extensions(self)
File
"/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py",
line 405, in build_extensions
self.build_extension(ext)
File "./setup.py", line 183, in build_extension
build_ext.build_extension(self, ext)
File
"/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py",
line 470, in build_extension
depends=ext.depends)
File "/tmp/Python-2.4.2c1/Lib/distutils/ccompiler.py",
line 699, in compile
self._compile(obj, src, ext, cc_args, extra_postargs,
pp_opts)
File "/tmp/Python-2.4.2c1/Lib/distutils/unixccompiler.py",
line 112, in _compile
self.spawn(self.compiler_so + cc_args + [src, '-o', obj] +
File "/tmp/Python-2.4.2c1/Lib/distutils/ccompiler.py",
line 1040, in spawn
spawn (cmd, dry_run=self.dry_run)
File "/tmp/Python-2.4.2c1/Lib/distutils/spawn.py", line
37, in spawn
_spawn_posix(cmd, search_path, dry_run=dry_run)
File "/tmp/Python-2.4.2c1/Lib/distutils/spawn.py", line
122, in _spawn_posix
log.info(string.join(cmd, ' '))
File "/tmp/Python-2.4.2c1/Lib/distutils/log.py", line 33,
in info
self._log(INFO, msg, args)
File "/tmp/Python-2.4.2c1/Lib/distutils/log.py", line 23,
in _log
print msg % args
TypeError: not enough arguments for format string
*** Error code 1
----------------------------------------------------------------------
Comment By: John Stone (jestone)
Date: 2005-09-29 15:33
Message:
Logged In: YES
user_id=48806
It's not an OS bug, it seems certain to be a build system
bug in Python,
please read on.
I did some more digging, and it appears that I can avoid
this problem by removing the "--without-gcc" flag to
configure. This flag is somehow interfering with the build
process. If I remove that flag and instead do the build
like this, I get much farther:
setenv CC "cc -xc99=%none -xarch=native64"
./configure
>From there, I run make and the build proceeds much much
farther successfully linking the python interpreter itself,
but ultimately fails just past that when using the
interpreter to do the rest:
ranlib libpython2.4.a
cc -xc99=%none -xarch=native64 -o python Modules/python.o
libpython2.4.a -lresolv -lsocket -lnsl -lrt
-ldl -lm
case $MAKEFLAGS in *-s*) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc
-xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python
-E ./setup.py -q build;; *) CC='cc -xc99=%none -xarch=native64' LDSHARED='cc
-xc99=%none -xarch=native64 -G' OPT='-DNDEBUG -O' ./python
-E ./setup.py build;; esac
running build
running build_ext
db.h: found (4, 2) in /usr/local/include
db lib: using (4, 2) db-4.2
INFO: Can't locate Tcl/Tk libs and/or headers
building 'struct' extension
creating build
creating build/temp.solaris-2.10-sun4u-2.4
Traceback (most recent call last):
File "./setup.py", line 1184, in ?
main()
File "./setup.py", line 1178, in main
scripts = ['Tools/scripts/pydoc', 'Tools/scripts/idle',
File "/tmp/Python-2.4.2c1/Lib/distutils/core.py", line
149, in setup
dist.run_commands()
File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line
946, in run_commands
self.run_command(cmd)
File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line
966, in run_command
cmd_obj.run()
File "/tmp/Python-2.4.2c1/Lib/distutils/command/build.py",
line 112, in run
self.run_command(cmd_name)
File "/tmp/Python-2.4.2c1/Lib/distutils/cmd.py", line 333,
in run_command
self.distribution.run_command(command)
File "/tmp/Python-2.4.2c1/Lib/distutils/dist.py", line
966, in run_command
cmd_obj.run()
File
"/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py",
line 279, in run
self.build_extensions()
File "./setup.py", line 178, in build_extensions
build_ext.build_extensions(self)
File
"/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py",
line 405, in build_extensions
self.build_extension(ext)
File "./setup.py", line 183, in build_extension
build_ext.build_extension(self, ext)
File
"/tmp/Python-2.4.2c1/Lib/distutils/command/build_ext.py",
line 470, in build_extension
depends=ext.depends)
File "/tmp/Python-2.4.2c1/Lib/distutils/ccompiler.py",
line 699, in compile
self._compile(obj, src, ext, cc_args, extra_postargs,
pp_opts)
File "/tmp/Python-2.4.2c1/Lib/distutils/unixccompiler.py",
line 112, in _compile
self.spawn(self.compiler_so + cc_args + [src, '-o', obj] +
File "/tmp/Python-2.4.2c1/Lib/distutils/ccompiler.py",
line 1040, in spawn
spawn (cmd, dry_run=self.dry_run)
File "/tmp/Python-2.4.2c1/Lib/distutils/spawn.py", line
37, in spawn
_spawn_posix(cmd, search_path, dry_run=dry_run)
File "/tmp/Python-2.4.2c1/Lib/distutils/spawn.py", line
122, in _spawn_posix
log.info(string.join(cmd, ' '))
File "/tmp/Python-2.4.2c1/Lib/distutils/log.py", line 33,
in info
self._log(INFO, msg, args)
File "/tmp/Python-2.4.2c1/Lib/distutils/log.py", line 23,
in _log
print msg % args
TypeError: not enough arguments for format string
*** Error code 1
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2005-09-29 06:21
Message:
Logged In: YES
user_id=21627
These look like bugs in the operating system. Please report
them to Sun.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1306253&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
