Bug 89781 - SRPMS: package doesn't build if configure test '-c -o support' failed
Summary: SRPMS: package doesn't build if configure test '-c -o support' failed
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: pygtk2
Version: 8.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Matt Wilson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-04-28 08:55 UTC by Sysoltsev Slawa
Modified: 2007-04-18 16:53 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-05-20 04:25:10 UTC
Embargoed:


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 08:57 UTC, Sysoltsev Slawa
no flags Details

Description Sysoltsev Slawa 2003-04-28 08:55:11 UTC
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:

Comment 1 Sysoltsev Slawa 2003-04-28 08:57:17 UTC
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 04:25:10 UTC
Please submit a patch to fix this either here or upstream.


Comment 3 Sysoltsev Slawa 2003-05-20 04:39:05 UTC
This is a bug in utilities from automake. Problem will dissolve after #89887 fix.

Comment 4 Matt Wilson 2003-05-20 04:56:08 UTC
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.