Bug 89781 - SRPMS: package doesn't build if configure test '-c -o support' failed
SRPMS: package doesn't build if configure test '-c -o support' failed
Product: Red Hat Linux
Classification: Retired
Component: pygtk2 (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Matt Wilson
Depends On:
  Show dependency treegraph
Reported: 2003-04-28 04:55 EDT by Sysoltsev Slawa
Modified: 2007-04-18 12:53 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-05-20 00:25:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Failure log done by `confugure && make` after hacking configure to fail `-c -o` test (1.82 KB, text/plain)
2003-04-28 04:57 EDT, Sysoltsev Slawa
no flags Details

  None (edit)
Description Sysoltsev Slawa 2003-04-28 04:55:11 EDT
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-
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" 
if test "${lt_cv_compiler_c_o+set}" = set; then
  echo $ECHO_N "(cached) $ECHO_C" >&6

$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 .
CFLAGS="$CFLAGS -o out/conftest2.$ac_objext"
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
  # Append any errors to the config.log.
  cat out/conftest.err 1>&5

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:

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:
Comment 1 Sysoltsev Slawa 2003-04-28 04:57:17 EDT
Created attachment 91329 [details]
Failure log done by `confugure && make` after hacking configure to fail `-c -o` test
Comment 2 Matt Wilson 2003-05-20 00:25:10 EDT
Please submit a patch to fix this either here or upstream.
Comment 3 Sysoltsev Slawa 2003-05-20 00:39:05 EDT
This is a bug in utilities from automake. Problem will dissolve after #89887 fix.
Comment 4 Matt Wilson 2003-05-20 00:56:08 EDT
Then please submit a patch to automake to fix the problem.

Note You need to log in before you can comment on or make changes to this bug.