homepage

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.

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
?

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.

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.

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.

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.

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.

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.

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.

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).

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?