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â¦
This is an upstream issue, which is still present in Libtool 1.5.