classification
Title: AIX: configure ignores $CC
Type: compile error Stage: resolved
Components: Build Versions: Python 3.1, Python 3.2, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: drj, jabt, nnorwitz, pitrou, r.david.murray, sable, smudd
Priority: normal Keywords:

Created on 2007-01-12 08:46 by jabt, last changed 2010-09-21 15:28 by pitrou. This issue is now closed.

Files
File name Uploaded Description Edit
configure.diff jabt, 2007-01-12 08:46 patch for configure
Messages (13)
msg30992 - (view) Author: Johannes Abt (jabt) Date: 2007-01-12 08:46
CC=xlc_r ./configure does not work on AIX-5.1, because configure unconditionally sets $CC to "cc_r":

	case $ac_sys_system in
	AIX*)   CC=cc_r
		without_gcc=;;


It would be better to leave $CC and just add "-qthreaded" to $CFLAGS. 

Furthermore, much of the C source code of Python uses C++ /C99 comments. This is an error with the standard AIX compiler. Please add the compiler flag "-qcpluscmt".

An alternative would be to use a default of "xlc_r" for CC on AIX. This calls the compiler in a mode that both accepts C++ comments and generates reentrant code.

Regards,
Johannes
msg30993 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2007-01-19 05:47
There shouldn't be any C++ comments in the Python code.  If there are, it is a mistake.  I did see some get removed recently.  Could you let me know where you see the C++ comments?
msg30994 - (view) Author: Johannes Abt (jabt) Date: 2007-01-30 13:07
Sorry about the C++ comments... all the C++ comments I have found concern
Windows, PC or Darwin. I must have confused this with another project
I have been compiling.

Though there still the issue with setting $CC.
msg30995 - (view) Author: Simon Mudd (smudd) Date: 2007-02-20 10:36
This issue also prevents trying to build Python with gcc on AIX which I am attempting at the moment.
While trying to resolve my own issue I have applied the following dirty patch to the python-2.5 tar ball.
The patch should allow you to set CC to a non standard value.

# Patch to make Python work with AIX and OpenPKG.
#
# This patch is NOT complete.
# - configure is not automatically recreated from configure.in
# - The correct behaviour for AIX should be to use CC if set and
#   otherwise to look for cc_r, cc and gcc (not sure about the order).
#
Index: configure.in
--- configure.in.orig   2007-02-19 15:19:32.000000000 +0100
+++ configure.in        2007-02-19 15:21:35.000000000 +0100
@@ -346,8 +346,15 @@
                without_gcc=$withval;;
        esac], [
        case $ac_sys_system in
-       AIX*)   CC=cc_r
-               without_gcc=;;
+       AIX*)
+               # set CC if not set already.
+               # - SHOULD enhance check to look for cc or gcc in case it
+               #   is in the PATH.
+               if /usr/bin/test -z "$CC"; then
+                       CC=cc_r
+                       without_gcc=
+               fi
+               ;;
        BeOS*)
                case $BE_HOST_CPU in
                ppc)
Index: configure
*** configure.orig      Tue Feb 20 10:14:18 2007
--- configure           Tue Feb 20 10:15:23 2007
***************
*** 1719,1726 ****
  else

        case $ac_sys_system in
!       AIX*)   CC=cc_r
!               without_gcc=;;
        BeOS*)
                case $BE_HOST_CPU in
                ppc)
--- 1719,1733 ----
  else

        case $ac_sys_system in
!       AIX*)
!               # set CC if not set already.
!               # - SHOULD enhance check to look for cc or gcc in case it
!               #   is in the PATH.
!               if /usr/bin/test -z "$CC"; then
!                       CC=cc_r
!                       without_gcc=
!               fi
!               ;;
        BeOS*)
                case $BE_HOST_CPU in
                ppc)
msg74230 - (view) Author: David Jones (drj) Date: 2008-10-03 08:18
This is still a problem for Python 2.6 on AIX 6.1.

The simplest fix is to change «CC=cc_r» to «CC=${CC:-xlc_r}» but I have no 
idea how to go about changing the configure script.
msg115209 - (view) Author: Sébastien Sablé (sable) Date: 2010-08-30 12:11
The workaround that I have been using is to call configure like this:

./configure --with-gcc=${CC}

(I usually define CC like this: export CC=xlc_r)

Python compiles fine on AIX 6.1 with that.
msg116378 - (view) Author: Sébastien Sablé (sable) Date: 2010-09-14 09:39
cc_r does not seems to be able to compile py3k, so it seems to be a bad idea to force it by default.

	cc_r -qlanglvl=extc89  -DNDEBUG -O -O2 -O2  -I. -IInclude -I./Include -I/home/cis/buildbot/support-buildbot/include -I/home/cis/buildbot/support-buildbot/include/ncurses -I/home/cis/buildbot/support-buildbot/include -I/home/cis/buildbot/support-buildbot/include/ncurses  -DPy_BUILD_CORE  -c ./Modules/posixmodule.c -o Modules/posixmodule.o
"./Modules/posixmodule.c", line 2580.26: 1506-046 (S) Syntax error.
"./Modules/posixmodule.c", line 2580.29: 1506-045 (S) Undeclared identifier Default.
make: 1254-004 The error code from the last command is 1.

The patch provided (configure.diff) is trivial and it only impacts AIX.
Could someone please apply it?
msg116380 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-09-14 10:12
> cc_r does not seems to be able to compile py3k, so it seems to be a bad 
> idea to force it by default.

Python should be able to compile with any C89-compliant compiler, so it seems a good idea to open a bug for compile errors instead.
In this case, the fix is trivial, though, so I'm simply committing it (replace a C++-style comment ("// ...") with a normal "/* ... */")). Can you try again with r84799?

That said, it seems xlc (or xlc_r) enables additional C extensions compared to cc, so perhaps it's beneficial to use it anyway?
msg116393 - (view) Author: Sébastien Sablé (sable) Date: 2010-09-14 12:14
cc(_r) and xlc(_r) refer to the same binary of the same compiler, but they change the default configuration of that compiler.

The documentation indicates:

 DESCRIPTION
         The invocation commands compile C and C++ source files.
         The commands and their recommended usages are described
         below.

         Invocations                   Usage (supported standards)
         _________________________________________________________

         xlc, xlc_r, xlc_r4,           Compile C source files.
         xlc_r7, xlc128, xlc128_r,     (ANSI C89, ISO C99,
         xlc128_r4, xlc128_r7          IBM language extensions)

         xlc++, xlc++_r, xlc++_r4,     Compile C++ source files.
         xlc++_r7, xlc++128,
         xlc++128_r, xlc++128_r4,
         xlc++128_r7, xlC, xlC_r,
         xlC_r4, xlC_r7, xlC128,
         xlC128_r, xlC128_r4,
         xlC128_r7

         cc, cc_r, cc_r4, cc_r7,       Compile legacy code that
         cc128, cc128_r, cc128_r4,     does not conform to Standard
         cc128_r7                      C. (pre-ANSI C)

         c89, c89_r, c89_r4,           Compile C source files with
         c89_r7, c89_128, c89_128_r,   strict conformance to the
         c89_128_r4, c89_128_r7        C89 standard. (ANSI C89)

         c99, c99_r, c99_r4,           Compile C source files with
         c99_r7, c99_128, c99_128_r,   strict conformance to the
         c99_128_r4, c99_128_r7        C99 standard. (ISO 99)

         xlc++core, xlc++core_r,       Compile C++ source files
         xlc++core_r7, xlc++core128,   but the compiler will
         xlc++core128_r,               link only to the core of
         xlc++core128_r7, xlCcore,     the runtime library.
         xlCcore_r, xlCcore_r7,
         xlC128core, xlC128core_r,
         xlC128core_r7

         gxlc                          Accepts GNU C options, maps
                                       them to their equivalent XL
                                       C option, then invokes xlc.

         gxlc++, gxlC                  Accepts GNU C/C++ options, maps
                                       them to their equivalent XL
                                       C++ option,then invokes xlc++.

         The main difference between these commands is that they
         use different default options (which are set in the
         configuration file /etc/vac.cfg.XX, where XX represents
         the AIX version).
         See the Compiler Reference for more information on these
         invocation commands.

         All invocations with a suffix of _r allow for thread-safe
         compilation. Use these commands to create threaded
         applications or to link programs that use multi-threading.

So xlc_r seems like the right one as the default to compile Python I would say.

I will check your last commit soon (I have buildbot nearly running on AIX, that is how I observed this problem actually).
msg116465 - (view) Author: Sébastien Sablé (sable) Date: 2010-09-15 16:26
Antoine, I tested your commit with cc_r and it compiles fine (I have buildbot running now, just need to find a way to make the results publicly browsable).

I still think xlc_r would be a better choice as a default: at the moment ctypes will not compile on AIX, but cc_r will fail as soon as when it compiles _ctypes.c, while xlc_r will compile this file fine but fail later on libffi/src/powerpc/ffi.c

cc_r -qlanglvl=extc89 -DNDEBUG -O -O2 -O2 -Ibuild/temp.aix-6.1-3.2/libffi/include -Ibuild/temp.aix-6.1-3.2/libffi -I/san_cis/home/cis/buildbot/buildbot-aix6/py3k/build/Modules/_ctypes/libffi/src -I. -I./Include -I/home/cis/buildbot/support-buildbot/include -I/home/cis/buildbot/support-buildbot/include/ncurses -I/usr/local/include -IInclude -I/san_cis/home/cis/buildbot/buildbot-aix6/py3k/build -c /san_cis/home/cis/buildbot/buildbot-aix6/py3k/build/Modules/_ctypes/_ctypes.c -o build/temp.aix-6.1-3.2/san_cis/home/cis/buildbot/buildbot-aix6/py3k/build/Modules/_ctypes/_ctypes.o
"build/temp.aix-6.1-3.2/libffi/include/ffi.h", line 133.27: 1506-207 (W) Integer constant 9223372036854775807 out of range.
"build/temp.aix-6.1-3.2/libffi/include/ffi.h", line 134.3: 1506-205 (S) #error "no 64-bit data type supported"
"/san_cis/home/cis/buildbot/buildbot-aix6/py3k/build/Modules/_ctypes/_ctypes.c", line 3222.27: 1506-068 (W) Operation between types "void*" and "int(*)(void)" is not allowed.
"/san_cis/home/cis/buildbot/buildbot-aix6/py3k/build/Modules/_ctypes/_ctypes.c", line 3766.31: 1506-280 (W) Function argument assignment between types "int(*)(void)" and "void*" is not allowed.
"/san_cis/home/cis/buildbot/buildbot-aix6/py3k/build/Modules/_ctypes/_ctypes.c", line 5386.63: 1506-280 (W) Function argument assignment between types "void*" and "void*(*)(void*,const void*,unsigned long)" is not allowed.
"/san_cis/home/cis/buildbot/buildbot-aix6/py3k/build/Modules/_ctypes/_ctypes.c", line 5387.62: 1506-280 (W) Function argument assignment between types "void*" and "void*(*)(void*,int,unsigned long)" is not allowed.
"/san_cis/home/cis/buildbot/buildbot-aix6/py3k/build/Modules/_ctypes/_ctypes.c", line 5388.65: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(const char*,int)" is not allowed.
"/san_cis/home/cis/buildbot/buildbot-aix6/py3k/build/Modules/_ctypes/_ctypes.c", line 5389.60: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(void*,struct _object*,struct _object*)" is not allowed.
"/san_cis/home/cis/buildbot/buildbot-aix6/py3k/build/Modules/_ctypes/_ctypes.c", line 5391.66: 1506-280 (W) Function argument assignment between types "void*" and "struct _object*(*)(const unsigned short*,int)" is not allowed.
msg116483 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-09-15 21:28
Sébastien, you could email Martin (tracker id loewis) about adding your buildbot to our unstable fleet (or even to stable if it is stable; that is, the tests normally pass and don't randomly fail).  As long as you are around to help fix bugs it would be great to have an aix buildbot in our buildbot fleet.

(NB: see also http://wiki.python.org/moin/BuildBot, which unfortunately is a bit out of date...)
msg117062 - (view) Author: Sébastien Sablé (sable) Date: 2010-09-21 15:11
I am currently in the process of correcting the building of Python on AIX and stabilizing the tests in order to add my buildbot as a slave of the official buildbot master, cf post on python-dev
http://mail.python.org/pipermail/python-dev/2010-September/103774.html

Could someone please commit this (IMO straightforward) patch?
msg117071 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-09-21 15:28
Ok, committed in r84946 (3.2), r84947 (3.1) and r84948 (2.7). Thank you!
History
Date User Action Args
2010-09-21 15:28:09pitrousetstatus: open -> closed
versions: - Python 2.6
messages: + msg117071

resolution: fixed
stage: resolved
2010-09-21 15:11:04sablesetmessages: + msg117062
2010-09-15 21:28:45r.david.murraysetnosy: + r.david.murray
messages: + msg116483
2010-09-15 16:26:10sablesetmessages: + msg116465
2010-09-14 12:14:32sablesetmessages: + msg116393
2010-09-14 10:12:35pitrousetnosy: + pitrou
messages: + msg116380
2010-09-14 09:39:51sablesettype: compile error
messages: + msg116378
versions: + Python 3.1, Python 2.7, Python 3.2
2010-08-30 12:11:03sablesetnosy: + sable
messages: + msg115209
2010-06-17 01:18:41terry.reedysetversions: - Python 2.5
2008-10-03 08:18:50drjsetnosy: + drj
messages: + msg74230
versions: + Python 2.6
2007-01-12 08:46:57jabtcreate