Multilib configure failing

[Ulrich Weigand <weigand at i1 dot informatik dot uni-erlangen dot de>]

Hello,

with current CVS head, multilib builds are broken (at least for
s390x, but probably for others as well).  The reason appears to
be the switch from autoconf 2.13 to 2.57 in some library subdirs.

When building a multilib library, we need to re-run configure
with the multilib flags specified in CC, so that the proper
decisions for that multilib target environment can be made.

To this purpose, config-ml.in reruns configure for each
multilib subdir with the command line

	${ml_config_env} ${ml_config_shell} ${ml_recprog} \
        --with-multisubdir=${ml_dir} --with-multisrctop=${multisrctop} \
        ${ac_configure_args} ${ml_srcdiroption}

${ml_config_env} contains strings to set the environment
variables CC, CXX etc. to the proper multilib values.  This
would cause a autoconf-2.13 generated configure script to
use these settings.

For autoconf-2.57 generated configure scripts, however, the
variable ${ac_configure_args} already contains the settings
for CC etc. in use with the *master* (non-multilib) build.
The presence of those arguments now causes configure to
completely ignore the environment variables CC etc. set up
by config-ml.in; in effect, the multilib configure runs
using exactly the same CC settings as the master configure.

Now, for most parameters determined by configure it does
not matter if the multilib flags are passed or not; however,
in some cases there *are* subtle differences.  Specifically,
the -m31 multilib of libf2c on s390x-ibm-linux fails to 
build because configure has mis-detected the proper linker
argument to build 31-bit shared libraries.

(Even more subtly, libf2c has a 2.13 configure script, so
it should work.  It doesn't, however, because all the 
various libraries for the same multilib flags share a
single config.cache.  This is initialized by the first
library to be configured, which happens to be the 2.57
autoconf'ed libiberty.  This writes an incorrent CC
setting to config.cache which gets then reused by all
subsequent target libraries.)

I've tried to fix this by passing the multilib CC values
as arguments instead of environment variables in config-ml.in.
Unfortunately, while this works fine for 2.57 configure
files, it completely breaks for 2.13 configure files, as
those don't accept variables on the command line.

The following patch works for me; it tries to detect whether
the master configure file is 2.57 or 2.13 (by checking if
there is already a CC setting passed on the command line)
and uses the method appropriate for each.

This way, I'm able to complete a multilibbed build of
s390x-ibm-linux.

However, this doesn't look like a particularly clean
solution to me; any suggestions how to fix this properly?


Bye,
Ulrich


Index: config-ml.in
===================================================================
RCS file: /cvs/gcc/gcc/config-ml.in,v
retrieving revision 1.29
diff -c -p -r1.29 config-ml.in
*** config-ml.in	17 Oct 2003 11:22:58 -0000	1.29
--- config-ml.in	18 Dec 2003 01:33:31 -0000
*************** if [ -n "${multidirs}" ] && [ -z "${ml_n
*** 858,866 ****
  	fi
      fi
  
      if eval ${ml_config_env} ${ml_config_shell} ${ml_recprog} \
  	--with-multisubdir=${ml_dir} --with-multisrctop=${multisrctop} \
! 	${ac_configure_args} ${ml_srcdiroption} ; then
        true
      else
        exit 1
--- 858,877 ----
  	fi
      fi
  
+     ml_configure_args=
+     for arg in ${ac_configure_args}
+     do
+       case $arg in
+  	*CC=*)  ml_configure_args=${ml_config_env} ;;
+ 	*CXX=*) ml_configure_args=${ml_config_env} ;;
+ 	*GCJ=*) ml_configure_args=${ml_config_env} ;;
+ 	*) ;;
+       esac
+     done
+ 
      if eval ${ml_config_env} ${ml_config_shell} ${ml_recprog} \
  	--with-multisubdir=${ml_dir} --with-multisrctop=${multisrctop} \
! 	${ac_configure_args} ${ml_configure_args} ${ml_srcdiroption}; then
        true
      else
        exit 1

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de