This is the mail archive of the
mailing list for the GCC project.
Re: Configure problem
- From: Jim Wilson <wilson at specifixinc dot com>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>,gcc-patches at gcc dot gnu dot org
- Date: 18 May 2004 18:39:34 -0700
- Subject: Re: Configure problem
- References: <20040510222926.GA15260@atrey.karlin.mff.cuni.cz><40A43262.firstname.lastname@example.org> <20040518211336.GA23631@nevyn.them.org>
On Tue, 2004-05-18 at 14:13, Daniel Jacobowitz wrote:
> How? When I do this, config.status is rerun, but configure isn't.
Good question. At the time, I was so convinced that I knew the answer
that I didn't double check my facts. I did manage to generate the same
error that Zdenek saw, but the commands I listed could not have done
I poked at this a bit, and came up with a way that I can reproduce.
The second make creates a config.cache file that has target_alias set.
The third make does a configure with target_alias unset, but sees the
config.cache file with it set, and complains about the discrepancy.
Someone is unlikely to do this by accident, but one way this can happen
Reconfiguring will delete the subdir Makefiles, to force them to be
By the way, I saw a new related problem today. The tree-ssa patch added
GMPINC and GMPLIB to the subconfigure variable list, but not the submake
variable list. So now it is possible to get the same problem in the gcc
directory with GMPINC and/or GMPLIB. They need to be added to
BASE_FLAGS_TO_PASS or something equivalent to fix this.
> * Makefile.tpl (configure-build-[+module+]): Export aliases
> for build targets.
> (configure-target-[+module+]): Likewise for target modules.
> (configure-[+module+], configure-gcc, configure-stage1-gcc)
> (configure-stage2-gcc, configure-stage3-gcc): Likewise for host
> * Makefile.in: Regenerated.
My patch was approved by DJ by the way. I didn't self approve it, and
the first version of my patch had a stupid mistake (patched a generated
file). I'll defer to the config maintainers if they want to comment.
I think exporting all of build/alias/target for all configures is
redundant. configure translates --build/--host/--target options into
build_alias/host_alias/target_alias variables. So there is no need to
export a variable that will be overridden by a configure option.
Also, there is a conflict here only because the sub-make export list
does not match the sub-configure export list. Only target_alias is in
the sub-make export list, so we really only need to put target_alias in
the sub-configure export list.
There is a problem for target subdirectories, because the toplevel
configure only passes the --build and --host options, and thus only
build_alias and host_alias get set in the resulting config.cache.
However, the make passes target_alias to sub-makes, causing all three of
build/host/target_alias to be set when running config.status --recheck
from a submake. So all we need to do is add target_alias to the
configure export list to solve this problem. We only need this for
target and build sub-configure rules.
An alternative solution would be to add --target options to
TARGET_CONFIGARGS and BUILD_CONFIGARGS.
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com