configure m4 problem
sezeroz at gmail.com
Fri Aug 20 13:33:51 CEST 2010
On Fri, Aug 20, 2010 at 1:40 PM, Ozkan Sezer <sezeroz at gmail.com> wrote:
> On Fri, Aug 20, 2010 at 1:18 PM, Niels Möller <nisse at lysator.liu.se> wrote:
>> Ozkan Sezer <sezeroz at gmail.com> writes:
>> Ok, this is the interesting piece.
>>> It seems like the problem (in our specific case, at least), is that 1)
>>> python sets the signal stuff, and 2) gcc's configure ends up setting
>>> $M4 because it's already found it anyway. In this case, $M4 gets
>>> propagated into flex.
>> Then it seems like a resonable improvement to GMPs configure script is
>> to always respect M4 set in the environment. Does any of the proposed
>> solutions do precisely that?
>> But some things are still puzzling me regarding your description of the
>> 1. Why does gcc set M4 in the environment? After a quick check of
>> gcc-4.4.4/configure, I don't see that it exports M4 (it is of course
>> substituted in Makefile.in etc., but that is something different).
>> 2. How come gmp's configure is started as a *subprocess* of gcc's
>> configure, hence inheriting that M4 environment variable? gmp wasn't
>> bundled with gcc last time I checked, but we might be using different
>> From this, I wonder if it's correct that the gcc configure script really
>> is the source of the M4 environment variable, I suspect that it is
>> instead set by some common ancestor process to both configure scripts.
>> Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
>> Internet email is subject to wholesale government surveillance.
> I can't say I fully understand the mechanism here, either. However,
> the thing happens ;) Another test shown in the original bug
> report (http://article.gmane.org/gmane.comp.lib.gmp.bugs/2114/) is
>> get gcc, put gmp in there, and like
>> mkdir /obj
>> cd /obj
>> python -c "import os;os.system('../gcc/configure && make')"
>> it'll take a while longer, but you'll get the above error.
> As for the suggested solutions in the original bug reports, which are:
>> a) get rid of the else entirely
>> b) set M4=m4
>> c) move this to after AM_PROG_LEX
> ... the first one, I think, would make gmp to always respect user-set
> M$ variable. An alternative to that might be, instead of completely
> removing the else case, setting it there only when M4 is not already
I mean something like:
@@ -3077,7 +3077,9 @@ if test $found_asm = yes; then
+ if test -z "$M4"; then
# Only do the GMP_ASM checks if there's a .S or .asm wanting them.
... just makes the standalone C testcase I posted reach to completion
successfully. Setting the variable to something non-existent is not to
my liking and I would do M4=m4, instead, but I'm surely leaving that
part to you guys.
More information about the gmp-devel