This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: --disable-multilib broken on GCC 3.4?
- From: Phil Edwards <phil at codesourcery dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: neroden at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: Fri, 30 Jan 2004 22:18:38 -0500
- Subject: Re: --disable-multilib broken on GCC 3.4?
- References: <200401310203.i0V23nb0009320@sirius.codesourcery.com>
On Fri, Jan 30, 2004 at 06:03:49PM -0800, Mark Mitchell wrote:
>
> In looking at the top-level configure script in GCC 3.4, I can't see
> anything that sets ${enable_multilib} before it is tested.
>
> That would seem to explain why configure --disable-multilib did not
> work for me.
>
> How is that supposed to work?
General --enable/--disable hook, in the massive '--' parsing switch statement:
-disable-* | --disable-*)
ac_feature=`echo $ac_option|sed -e 's/-*disable-//'`
....
ac_feature=`echo $ac_feature| sed 's/-/_/g'`
eval "enable_${ac_feature}=no" ;;
Normally, enable/disable switches have a default case, set just before they
get used. Looking at the toplevel configure, it looks like the next place
involving multilibs is
# Default to --enable-multilib.
if test x${enable_multilib} = x ; then
target_configargs="--enable-multilib ${target_configargs}"
fi
which still doesn't set it at the toplevel, but will set it for the libraries.
--
Besides a mathematical inclination, an exceptionally good mastery of
one's native tongue is the most vital asset of a competent programmer.
- Edsger Dijkstra, 1930-2002