configure m4 problem

[Ozkan Sezer]

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:
>>
>>>   putenv("M4=m4");
>>
>> 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
>> setup.
>>
>> 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
>>   versions/distributions.
>>
>> 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.
>>
>> Regards,
>> /Niels
>>
>> --
>> 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
> this:
> [...]
>>  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
> set.

I mean something like:

--- configure.in.orig
+++ configure.in
@@ -3077,7 +3077,9 @@ if test $found_asm = yes; then
   GMP_PROG_M4
   GMP_M4_M4WRAP_SPURIOUS
 else
-  M4=m4-not-needed
+  if test -z "$M4"; then
+     M4=m4-not-needed
+  fi
 fi

 # 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.

Regards.

--
Ozkan