Bug 89887

Description of problem:
As a part of macro AM_PROG_LIBTOOL in configure.in test âif $compiler 
supports -c -o file. $ac_objextâ is included into configuration scripts. If you have 
confugure.in consists of only line AM_PROG_LIBTOOL
and start aclocal, aclocal.m4 will be created; it will contain such test:

# Check to see if options -o and -c are simultaneously supported by compiler
AC_MSG_CHECKING([if $compiler supports -c -o file.$ac_objext])
AC_CACHE_VAL([lt_cv_compiler_c_o], [
$rm -r conftest 2>/dev/null
mkdir conftest
cd conftest
echo "int some_variable = 0;" > conftest.$ac_ext
mkdir out
# According to Tom Tromey, Ian Lance Taylor reported there are C compilers
# that will create temporary files in the current directory regardless of
# the output directory.  Thus, making CWD read-only will cause this test
# to fail, enabling locking or at least warning the user not to do parallel
# builds.
chmod -w .
save_CFLAGS="$CFLAGS"
CFLAGS="$CFLAGS -o out/conftest2.$ac_objext"
compiler_c_o=no
if { (eval echo configure:__oline__: \"$ac_compile\") 1>&5; (eval $ac_compile) 
2>out/conftest.err; } && test -s out/conftest2.$ac_
  # The compiler can only warn and ignore the option if not recognized
  # So say no if there are warnings
  if test -s out/conftest.err; then
    lt_cv_compiler_c_o=no
  else
    lt_cv_compiler_c_o=yes
  fi
else
  # Append any errors to the config.log.
  cat out/conftest.err 1>&AC_FD_CC
  lt_cv_compiler_c_o=no
fi
â¦

This test tries compiler with ââc âo out/coftest.$ac_objextâ option and is passed if:
1. compiler exits successfully
2. output file is created
3. there is nothing in compiler stderr output
This is quite OK, but before calling compiler script denies writing to the current 
directory (as I understand motivation is in comment). So it seems that within â-c â
oâ support test there is ANOTHER test for ability of compiler to work without 
creating temporary files in current directory. This test must be separated because 
this feature is NOT needed for general build process, while â-c âoâ tests are needed 
and quite usual.
GNU compiler does not use temporary files usually and does not expose the 
problem. Thatâs why several packages from Linux Distributions (pygtk2 (see 
tracker #89781), netatalk) do not handle the case when â-c âoâ test fails. In such 
cases building process becomes broken. 
Intel compiler does support â-c âoâ combination, but also uses temporary files, 
creating them in current directory.  These file have unique name and are removed 
after compilation. How can it hurt build process? And whatâs the connection of 
temporary files compilerâs behavior with â-c âoâ support ??? Nevertheless  â-c âoâ 
fails with Intel compiler and build process cannot straighten up. That cause 
package build to fail in libtool that cannot find output file because itself suppress â
o option due to such a misconfiguration!
Configuration itself is very complicated process, scripts should be clear. Thatâs 
why test for â-c âoâ support and test for where temporary files are created must be 
separated. That would only increase Red Hat Linux portability and reliability.

Version-Release number of selected component (if applicable):


How reproducible:
always

Steps to Reproduce:
1. Be in empty directory and have automake installed
2. echo AM_PROG_LIBTOOL > configure.in
3. aclocal.m4 will contain invalid test â# Check to see if options -o and -c are 
simultaneously supported by compilerâ
In case of real package this test goes to configure script afterwards.
See tracker #89781 if you wish to see real error happened. Also such situation 
happens in netatalk package (and may be in more packages).
    
Actual results:
â-c âoâ test may be failed though compiler support â-c âoâ combination.
Exactly that happens with latest versions of Intel compiler.

Expected results:
â-c âoâ test must test only feature it intended test to.

Additional info:
I would try to push Intel compiler to generate temporary file somewhere else or use 
pipes but how could I motivate that temporary files cannot be in current directory? 
It seems quite naturalâ¦