configure m4 problem

[Ozkan Sezer]

On Fri, Aug 20, 2010 at 11:13 AM, Niels Möller <nisse at lysator.liu.se> wrote:
> Ozkan Sezer <sezeroz at gmail.com> writes:
>
>> M4 is a configure user variable and it is supposed to be exported.
>> See the generated configure file, it is in ac_subst_vars.
>
> Now we're talking about different things. The M4 variable surely is
> intended to be substituted in files like Makefile.in. What I question is
> if it is intended to be exported as an environment variable to
> subprocesses started by configure. I don't see any
>
>  export M4
>
> in the generated configure script, but I may of course be missing
> something.
>
>> Although the GMP_PROG_M4 respects user-set M4 variable, GMP's
>> configure.in doesn't respect it and override it
>
> You do have a user-set M4 variable? If so, that's new and crucial
> information. I'm getting even more confused about what the problem you
> are reporting really is. Is the problem that you have a user-set M4, and
> GMPs configure is not respecting it?
>
>> Can you please tell us what is wrong with the suggested solutions?
>
> No.
>
> I cannot do that, because I don't yet understand the problem those
> proposed solutions are intended to solve.
>
> Regards,
> /Niels
>

In the hopes that this will help demonstrate the problem: testcase
inlined below (run next to gmp's configure, nothing else needed).

$ cat test.c
#include <signal.h>
#include <unistd.h>
#include <stdlib.h>
int main() {
  putenv("M4=m4");
  signal(SIGPIPE, SIG_IGN);
  execlp("./configure",
         "./configure",
         "--host=none-none-none",
         NULL);
  return 0;
}

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.

--
Ozkan