Emmanuel Thomé Emmanuel.Thome at gmail.com
Sat Dec 11 17:39:13 CET 2010

On Sat, Dec 11, 2010 at 05:16:23PM +0100, Torbjorn Granlund wrote:
> Emmanuel Thomé <Emmanuel.Thome at gmail.com> writes:
>   When gmp is configured with no assembly, as is done e.g. when gcc is
>   compiled with the gmp source present, the following environment variable
>   gets set from within ./configure:
>       M4=m4-not-needed
>   Indeed, as there is no assembly code to manipulate with m4, m4 is not
>   needed.
>   However, the M4 variable seems to have an unfortunate effect on flex:
>   ethome at suno-7:/tmp/gcc-build/gmp$ M4=m4-not-needed flex conftest.l 
>   flex: fatal internal error, exec failed
>   (where conftest.l is the one from the gmp configure, for that matter).
> Is flex run from within GMP, or is the M4 setting somehow inherited out
> from GMP?

I'm not sure I understand your question.

flex is run from within gmp's configure. I assume it's possibly needed for the
calc demo (?). The only thing configure needs to know is the name of the
output file, e.g. whether it's lex.yy.c or something else.

Since flex is from from gmp's configure, the changes to $M4 which are
made by the configure script propagate to the children processes of
course, including flex.

>   Under *some* circumstances (I come across this deterministically while
>   running a gcc compile from a batch job, however I haven't been able to
>   reproduce it live), it leads to lex.yy.c not being created, eventually
>   causing the configure script to abort (possibly a sigpipe/wait/unlink
>   race).
> I think you have different PATHs in your batch job and 'live', and thus
> find different flex commands.

I'm not sure of this. In any case the sed fix I posted earlier does fix the
issue in my batch job.

>   I see that the mercurial code now leaves the variable M4 untouched in
>   case it already exists, which seems more reasonable than overriding it
>   with bogus content unconditionally. However I wonder why gmp touches the
>   M4 variable in the first place in this case. May I suggest leaving this
>   variable untouched instead ? Or is there a compelling reason for setting
>   m4-not-needed ?
> I don't recall why this was made, and I cannot find any helpful
> ChangeLog entry.



More information about the gmp-bugs mailing list