nightstrike at gmail.com
Sun Dec 12 17:35:11 CET 2010
On 12/12/10, Jay K <jay.krell at cornell.edu> wrote:
> This is not the cause of the overall problem.
> i.e. it is not my case, and I fully understand and have seen the
> problem in question. Should I explain it again? The problem
> has many steps so my explanations have perhaps been unclear.
You have explained it many times, I have explained it, others on my
project have explained it, and others outside of us have explained it.
The GMP project has been characteristically obstinate in dealing with
the issue, just like they are with many other things (see our
multi-year efforts to get GMP to stop assuming sizeof long == sizeof
pointer so that Win64 can work). It is a shame that GCC has a hard
dependency on the project, otherwise, I would gladly erase it from my
>> 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.
> That is slightly better, as it allows a workaround in the caller of M4=m4.
> But still, caller should not have to set M4.
That was a kludge to paper over another kludge. The basic premise of
the exceedingly trivial implementation is flawed. What is so mind
boggling is that to do it the "right" way requires a one line change
that the GMP project has continually refused to do, offerring no
reason as to why.
> As well, it should be clear, if you don't gmp/configure "none", then M4=m4,
> and flex "works"
> in a more normal way -- running m4 works, no signal.
It doesn't "work". The shoddy code goes unnoticed because of a side
effect of the original kludge. That doesn't make the code any less
wrong, just less apparent. Clobbering a user variable (of which M4 is
according to configure --help) is always wrong.
> It is unfortunate that $M4 is used by flex.
There's nothing wrong with this, actually. M4 is an official variable
used by autoconf that can be overridden by the user just like CC and
everything else. See
for details. A project should never hack up this variable and use it
for some backwards internal purpose.
> But as such, gmp/configure should not touch it.
For more reasons than you have stated.
> For gmp/configure, M4 is meant to just be an internal temporary variable.
> It does not mean to pass it on down to flex.
> In fact, I think it doesn't export it. That it is exported might be due to
> running as part of gcc/configure. Or, perhaps, as part of the presumably
> used feature of getting flex to use it.
See above. It is exported, and it does pass it down on purpose. This
is exactly why GMP shouldn't use it.
> (I suspect others would volunteer as well: Nightstrike and Emmanuel?)
It really comes down to the project itself, and whether they want to
pull their heads out of the sand.
More information about the gmp-bugs