Issue 533188: configure.in Assumes cc_r Exists on AIX. (original) (raw)

Created on 2002-03-21 17:12 by ralph, last changed 2022-04-10 16:05 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
cc_r.patch ralph,2002-03-22 17:08 cc_r.patch
Messages (11)
msg9858 - (view) Author: Ralph Corderoy (ralph) Date: 2002-03-21 17:12
Running plain `./configure' on an AIX 3.2.5 machine fails. configure:966: checking whether the C compiler (cc_r ) works configure:982: cc_r -o conftest conftest.c 1>&5 ./configure: cc_r: not found configure: failed program was: #line 977 "configure" #include "confdefs.h" main(){return(0);} Here's details about the machine. $ uname -a AIX anon 2 3 000038834100 $ oslevel >3250 cc_r doesn't exist. cc does. Running configure thus $ ./configure --without-gcc as a workaround lets configure successfully complete. configure.in assumes $CC should be cc_r if no --with-gcc or --without-gcc option is given and if the system is AIX. This seems wrong. Instead, perhaps it should search for the first cc that works with an order of preference to cc_r, then cc.
msg9859 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2002-03-22 10:06
Logged In: YES user_id=6656 Thanks for the report. Can you come up with a patch? I can probably bodge something together if not, but it's obviously easier to test. Does the build actually work after ./configure --without-gcc ?
msg9860 - (view) Author: Ralph Corderoy (ralph) Date: 2002-03-22 17:08
Logged In: YES user_id=911 I've attached a possible patch. It seems right in theory but I'm not experienced with autoconf. Unfortunately, I can't test the patch because I can't re-generate configure on this system -- I guess I have incompatible versions of autoconf, automake, etc. If you want to email me the resulting configure I'd be happy to try it.
msg9861 - (view) Author: Ralph Corderoy (ralph) Date: 2002-03-22 17:10
Logged In: YES user_id=911 PS. No, it doesn't continue to build sucessfully. But that's another bug report I've yet to raise and is unrelated AFAICS to this problem.
msg9862 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-03-22 17:54
Logged In: YES user_id=21627 It appears that cc_r got introduced by patch python.org/sf/403679. I recommend to consult donnc why he thinks that the compiler is named cc_r on AIX.
msg9863 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2002-03-22 18:00
Logged In: YES user_id=21627 Please have a look at http://www.openldap.org/lists/openldap-bugs/199812/msg00044.html This claims that using cc_r on AIX is mandatory, as this is the the compiler that generates thread-safe executables.
msg9864 - (view) Author: Donn Cave (donnc) Date: 2002-03-22 18:34
Logged In: YES user_id=42839 I can't account for the absence of cc_r, but it doesn't pay to try to understand IBM. The compiler we have here mentions cc_r at the top of the "man" (from "info") page, along with xlc_r, cc_r4, cc_r7 and all permutations. Looking in /etc/xlC.cfg, _r means "AIX threads", _r4 "DCE" [threads] and _r7 is missing. The "r" stands for "reentrant", and I know from experience that the code linked by cc_r has extra mutexes etc. Without cc_r, just don't enable threads.
msg9865 - (view) Author: Ralph Corderoy (ralph) Date: 2002-03-22 21:34
Logged In: YES user_id=911 Replying to a few comments at once... The C compiler on AIX comes in many guises. They are normally all hard links to the same executable. /etc/xlc.cfg defines these identities, so cc_r, if it exists, just causes a certain set of options to be used. * extended c compiler aliased as cc_r cc_r: use = DEFLT crt = /lib/crt0_r.o mcrt = /lib/mcrt0.o gcrt = /lib/gcrt0.o libraries = -L/usr/lib/dce,-lc_r,-lpthreads proflibs = -L/lib/profiled,-L/usr/lib/profiled options = -H512,-T512,-qlanglvl=extended, -qnoro,-D_THREAD_SAFE,-D_CMA_NOWRAPPERS_, -qnoroconst So http://www.openldap.org/lists/openldap-bugs/199812/msg00044.html is wrong when it says that you can't use cc with an appropriate set of options since that's all that cc_r, cckern, c89, xlc_r, or any of the other hard links are. However, not all AIX installations have all bits of the C compiler available to support all its guises. So I think it's preferable to use cc_r if it is available, else fall-back on cc. And if using cc hopefully configure's testing for whether threads is available will determine it isn't. This is all based on AIX 3, AIX 4 expanded on this in a few ways. In summary, I'd agree with donnc `Without cc_r, just don't enable threads'. Hopefully, that'll happen automatically.
msg9866 - (view) Author: Ralph Corderoy (ralph) Date: 2002-03-23 00:43
Logged In: YES user_id=911 BTW, the build then halts because 1.295 of configure.in isn't in the release candidate so LINKCC's definition in Makefile contains LINKCC and the recursion isn't welcome. SF bug #477487 apparently.
msg9867 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2002-03-25 13:36
Logged In: YES user_id=6656 I'm getting lost. What action is needed? The LINKCC thing was fixed, but I forgot to run autoconf before building the 2.2.1c1 tarball (sorry).
msg9868 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2002-03-31 20:15
Logged In: YES user_id=6656 I'm proposing to close this, maybe adding a note to the README that says "if in difficulties, run ./configure -- without-gcc". Objections?
History
Date User Action Args
2022-04-10 16:05:08 admin set github: 36304
2002-03-21 17:12:18 ralph create