classification
Title: configure detects incorrect compiler optimization
Type: compile error Stage: resolved
Components: Build, Installation Versions: Python 3.1, Python 2.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: loewis Nosy List: CoryZ, amaury.forgeotdarc, gschwarz, koobs, laca, loewis, movement, mschmarck, pitrou, r.david.murray, sable
Priority: normal Keywords:

Created on 2004-01-14 21:05 by gschwarz, last changed 2014-02-03 15:50 by BreamoreBoy.

Messages (12)
msg19689 - (view) Author: Georg Schwarz (gschwarz) Date: 2004-01-14 21:05
the configure script checks whether $CC compiles with -OPT:Olimit=0. For IRIX 5.3's cc, for example, although it is not supported, it only gives a warning and compiles nonetheless:

cc -OPT:Olimit=0 c.c
cc: Warning: -OPT options are ignored

The configure script tests do not check for this, so they do use that option. It's not so much of a problem that we constantly get respective warnings while
compiling; what's more of a problem (and therefore I call it a bug) is that python's configure does not go on checking for other optimizations. Therefore, on IRIX 5.3 with cc the -Olimit=1500 option, which would be needed, is not being configured.

Suggestion: also check whether there's anything on stderr while compiling the test code, and if so, don't use that particular option. Assuming make uses some /bin/sh you might use cc -OPT:Olimit=0 c.c 2>&1 >/dev/null and check whether there's any output (or maybe there are more elegant solutions).
msg72497 - (view) Author: Michael Schmarck (mschmarck) Date: 2008-09-04 12:30
This still happens with Python 2.6b3, 3.0b3 and 2.5.2 and Sun Studio 12
on Solaris Sparc.

Like mentioned in Issue1162001, the problem seems to be, that cc returns
0 if -OPT:Olimit=0 is used:

--($ ~)-- cc  -OPT:Olimit=0 test1.c; echo $?
cc: Warning: illegal option -OPT:Olimit=0
0

--($ ~)-- gcc  -OPT:Olimit=0 test1.c; echo $?
cc1: error: invalid option argument `-OPT:Olimit=0'
1

I ran this configure:

CXX=/opt/SUNWspro/bin/CC CC=/opt/SUNWspro/bin/cc ./configure
--prefix=$HOME/.software/python-2.6b3 --disable-ipv6 --enable-shared
--without-gcc --with-threads --with-doc-strings

The prefix was always different, of course :)

--($ ~)-- gcc --version
gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

--($ ~)-- version # for cc
Machine hardware:   sun4u
OS version:         5.10
Processor type:     sparc
Hardware:           SUNW,Sun-Fire-480R

The following components are installed on your system:


Sun Studio 12
        Sun Studio 12 C Compiler
        Sun Studio 12 C++ Compiler
        Sun Studio 12 Tools.h++ 7.1
        Sun Studio 12 C++ Standard 64-bit Class Library
        Sun Studio 12 Garbage Collector 
        Sun Studio 12 Fortran 95 
        Sun Studio 12 Debugging Tools (including dbx)
        Sun Studio 12 IDE
        Sun Studio 12 Debugger GUI
        Sun Studio 12 Performance Analyzer (including collect, ...)
        Sun Studio 12 X-Designer 
        Sun Studio 12 VIM editor
        Sun Studio 12 XEmacs editor
        Sun Studio 12 Performance Library 
        Sun Studio 12 LockLint
        Sun Studio 12 Building Software (including dmake)
        Sun Studio 12 Documentation Set

version of "/opt/SUNWspro/bin/../prod/bin/../../bin/cc": Sun C 5.9
SunOS_sparc Patch 124867-01 2007/07/12
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/CC": Sun C++ 5.9
SunOS_sparc Patch 124863-01 2007/07/25
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/f90": Sun Fortran 95
8.3 SunOS_sparc Patch 127000-01 2007/07/18
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/dbx": Sun Dbx
Debugger 7.6 SunOS_sparc Patch 124872-01 2007/07/12
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/analyzer": Sun
Analyzer 7.6 SunOS_sparc Patch 126995-01 2007/07/17
version of "/opt/SUNWspro/bin/../prod/bin/../../bin/dmake": Sun
Distributed Make 7.8 SunOS_sparc Patch 126503-01 2007/07/19
msg82202 - (view) Author: John Levon (movement) Date: 2009-02-16 01:31
Yep, this is an annoying misfeature of Sun Studio. There is no way to
affect this behaviour. There is a Sun Studio bug filed for this
(-errwarn should affect this behaviour, but it doesn't).

Here's some example m4 that libvirt uses to check this case properly:

AC_DEFUN([gl_COMPILER_FLAGS],
  [AC_MSG_CHECKING(whether compiler accepts $1)
   AC_SUBST(COMPILER_FLAGS)
   ac_save_CFLAGS="$CFLAGS"
   CFLAGS="$CFLAGS $1"
   AC_TRY_LINK([], [], has_option=yes, has_option=no,)
   echo 'int x;' >conftest.c
   $CC $CFLAGS -c conftest.c 2>conftest.err
   ret=$?
   if test $ret != 0 -o -s conftest.err -o $has_option = "no"; then
       AC_MSG_RESULT(no)
   else
       AC_MSG_RESULT(yes)
       COMPILER_FLAGS="$COMPILER_FLAGS $1"
   fi
   CFLAGS="$ac_save_CFLAGS"
   rm -f conftest*
 ])
msg114307 - (view) Author: Mark Lawrence (BreamoreBoy) Date: 2010-08-19 00:06
This is a Sun Studio problem not a Python problem.
msg114308 - (view) Author: John Levon (movement) Date: 2010-08-19 00:10
That's a little abrupt. Whilst it would be nice if the compiler had a correct return value, it occurs with multiple compilers, and I pointed
you to a suitable workaround Python could employ. Even if Studio gets fixed, there are previous releases out there for a long time.
msg114309 - (view) Author: John Levon (movement) Date: 2010-08-19 00:11
Even worse, a nasty hack was added just for Intel's compiler as seen in
http://bugs.python.org/issue1162001
msg114311 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-08-19 00:35
I agree, it is the job of the autotools to handle system portability
issues such as this, and thus this can be considered a fixable bug.
However, it is the kind of thing that is only going to get fixed if
someone whom it affects can propose a patch, since I doubt any of the
current active committers have affected systems on which to test it.

The patch should be against the py3k trunk, and we'll need at least one
other person whom this affects to review the patch before a committer
can apply it.
msg128584 - (view) Author: Sébastien Sablé (sable) Date: 2011-02-15 11:49
If have the same issue with Oracle Studio 12.2 on Solaris 10 with Python 2.7.1:

....
cc -G -L/livraison/test/sparc-sun-solaris2.10/support/support-2.6.x-py27/lib -L/livraison/test/sparc-sun-solaris2.10/support/support-internal-2.6.x-py27/lib -L/livraison/test/sparc-sun-solaris2.10/support/support-2.6.x-py27/lib -L/livraison/test/sparc-sun-solaris2.10/support/support-internal-2.6.x-py27/lib -OPT:Olimit=0 -g -DNDEBUG -xO4 -I. -IInclude -I./Include -I/livraison/test/sparc-sun-solaris2.10/support/support-2.6.x-py27/include -I/livraison/test/sparc-sun-solaris2.10/support/support-2.6.x-py27/include/ncurses -I/livraison/test/sparc-sun-solaris2.10/support/support-internal-2.6.x-py27/include build/temp.solaris-2.10-sun4u-2.7/san_u10/home/recette/ssa/support-2.6.x/Python-2.7.1/Modules/_struct.o -L/livraison/test/sparc-sun-solaris2.10/support/support-2.6.x-py27/lib -L/usr/local/lib -L. -lpython2.7 -o build/lib.solaris-2.10-sun4u-2.7/_struct.so
cc: Warning: Option -OPT:Olimit=0 passed to ld, if ld is invoked, ignored otherwise
/usr/ccs/bin/ld: illegal option -- O
usage: ld [-6:abc:d:e:f:h:il:mo:p:rstu:z:B:CD:F:GI:L:M:N:P:Q:R:S:VY:?] file(s)
msg128585 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-02-15 11:57
Was fixed in r85656 by Martin (in 3.2), but needs backporting.
msg190045 - (view) Author: Mark Lawrence (BreamoreBoy) Date: 2013-05-26 01:02
Who is best placed to backport the fix?
msg190113 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2013-05-26 20:46
The 3.2 change r85656 removes OPT:Olimit, IMO this should not be backported.

But 2.7 already has this warning fixed for icc:
http://hg.python.org/cpython/rev/e7c96c1d144b/
We should do the same here. What's the correct way to detect Oracle Studio compiler?
msg200371 - (view) Author: koobs (koobs) Date: 2013-10-19 05:06
This also affects Python 2.7 / 3.1 on FreeBSD 10.x with CC=clang

Referencing the PR here: http://www.freebsd.org/cgi/query-pr.cgi?pr=182952

Would like to see the commit backported as well.
History
Date User Action Args
2014-02-03 15:50:47BreamoreBoysetnosy: - BreamoreBoy
2013-10-19 05:06:37koobssetnosy: + koobs
messages: + msg200371
2013-05-26 20:46:49amaury.forgeotdarcsetnosy: + amaury.forgeotdarc
messages: + msg190113
2013-05-26 01:02:58BreamoreBoysetmessages: + msg190045
2012-05-28 12:49:23CoryZsetnosy: + CoryZ
2011-02-15 11:57:44pitrousetversions: - Python 3.2
nosy: + pitrou, loewis

messages: + msg128585

assignee: loewis
stage: needs patch -> resolved
2011-02-15 11:49:00sablesetnosy: + sable
messages: + msg128584
2010-08-19 00:35:24r.david.murraysetstatus: closed -> open

versions: + Python 3.1, Python 2.7, Python 3.2, - Python 2.6, Python 3.0
nosy: + r.david.murray

messages: + msg114311
resolution: not a bug ->
stage: needs patch
2010-08-19 00:11:49movementsetmessages: + msg114309
2010-08-19 00:10:09movementsetmessages: + msg114308
2010-08-19 00:06:28BreamoreBoysetstatus: open -> closed

nosy: + BreamoreBoy
messages: + msg114307

resolution: not a bug
2009-02-16 01:38:33lacasetnosy: + laca
2009-02-16 01:31:33movementsetnosy: + movement
messages: + msg82202
2009-02-14 12:31:45ajaksu2settype: compile error
components: + Build
versions: - Python 2.5, Python 2.4
2008-09-04 12:30:52mschmarcksetversions: + Python 2.6, Python 2.4, Python 3.0
2008-09-04 12:30:17mschmarcksetnosy: + mschmarck
messages: + msg72497
versions: + Python 2.5, - Python 2.4
2004-01-14 21:05:04gschwarzcreate