jay.krell at cornell.edu
Fri Dec 10 12:46:03 CET 2010
> From: Emmanuel
> Subject: m4-not-needed
> 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:
> Indeed, as there is no assembly code to manipulate with m4, m4 is not
> 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).
> 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
> 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 ?
Indeed! This is gross. Other people see it. It is easy to fix.
I reported it with a bit more information over two years ago.
One could concievable blame Python's use of signal(SIGPIPE)
but really gmp configure should just not touch the M4 variable.
Use _GMP_CONFIGURE_M4 or such if it must.
I've actually since gone and removed all the gmp/mpfr/mpc dependencies
from our fork of gcc 4.5.1, with maybe some lost optimizations...
More information about the gmp-bugs