Description of problem: I tried to build pygtk2 by Intel compiler and got such strange error: Making all in gtk make[2]: Entering directory `/home/users/compiler/tc_4/WORK_DIR/BUILD/pygtk- 1.99.12/gtk' source='gtkmodule.c' object='_gtkmodule_la-gtkmodule.lo' libtool=yes \ depfile='.deps/_gtkmodule_la-gtkmodule.Plo' tmpdepfile='.deps/_gtkmodule_la- gtkmodule.TPlo' \ depmode=gcc /bin/sh ../depcomp \ /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. - I/usr/include/python2.2 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include - I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/Xft2 - I/usr/include/freetype2 -I/usr/X11R6/include -I/usr/include/glib-2.0 -I/usr/lib/glib- 2.0/include -g -O2 -Wall -std=c9x -c -o _gtkmodule_la-gtkmodule.lo `test - f 'gtkmodule.c' || echo './'`gtkmodule.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I/usr/include/python2.2 -I/usr/include/gtk- 2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 - I/usr/include/Xft2 -I/usr/include/freetype2 -I/usr/X11R6/include -I/usr/include/glib- 2.0 -I/usr/lib/glib-2.0/include -g -O2 -Wall -std=c9x -c gtkmodule.c -Wp,- MD,.deps/_gtkmodule_la-gtkmodule.TPlo -fPIC -DPIC mv -f _gtkmodule_la-gtkmodule.o _gtkmodule_la-gtkmodule.lo mv: cannot stat `_gtkmodule_la-gtkmodule.o': No such file or directory Obviously problem here because '-o _gtkmodule_la-gtkmodule.o' is omitted in command line. Why? That's because configure determined that compiler does not support '-c -o' combination. But I know that it DOES! Looking into test in configure I found that it not only checks output file in current directory but enforce it by denying writing into current directory. Here is quote from configure: # Check to see if options -o and -c are simultaneously supported by compiler echo "$as_me:$LINENO: checking if $compiler supports -c -o file.$ac_objext" >&5 echo $ECHO_N "checking if $compiler supports -c -o file.$ac_objext... $ECHO_C" >&6 if test "${lt_cv_compiler_c_o+set}" = set; then echo $ECHO_N "(cached) $ECHO_C" >&6 else $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:4811: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>out/conftest.err; } && test -s out/conftest2.$ac_objex # 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>&5 lt_cv_compiler_c_o=no fi Occasionally happens that Intel compiler I use creates temporary files in current directory but it strongly watches that they have an UNIQUE name. How could it bother build ? And whatâs the deal with ââc âoâ test ? It seems that configure test is invalid, it does not test feature properly. Because build process does not generate configure from configure.in, it is a bug of packager. The second problem, if configure test â-c âoâ fails, build become unconditionally broken. Makefile transfer control over compilation .c->.lo to libtool that is unable to handle it if sure that compiler cannot handle -c -o combination (it just suppress -o filename). Thatâs why it cannot find object files with fuzzy names during move. Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. `rpmbuild âbp` source package 2. Crack configure to always fail â-c âoâ test 3. try `configure && make` - it will fail (log attached) Actual results: Successfully built package Expected results: Dumb error on âmvâ action Additional info:
Created attachment 91329 [details] Failure log done by `confugure && make` after hacking configure to fail `-c -o` test
Please submit a patch to fix this either here or upstream.
This is a bug in utilities from automake. Problem will dissolve after #89887 fix.
Then please submit a patch to automake to fix the problem.