configure m4 problem
sezeroz at gmail.com
Thu Aug 19 21:46:06 CEST 2010
On Thu, Aug 19, 2010 at 11:15 AM, Niels Möller <nisse at lysator.liu.se> wrote:
> Ozkan Sezer <sezeroz at gmail.com> writes:
>> This is what I got from our builders / configury maintainers:
>> "The configure script is running flex using a nonexistent M4.
>> That causes a sigpipe, which leaves a useless orphaned file.
>> The configure script looks at that and says "ok, flex works".
>> Under python, sigpipe gets filtered out. So, flex cleans up
>> after itself (as it should), thus deleting the file, and so
>> the configure script thinks flex is broken (when in reality,
>> the configure script is wrong and flex reported correctly.)
>> M4 can't be defined before running AM_PROG_LEX, and it should
>> not be defined al all in that fashion, either."
> As far as I see, the configure script does not explicitly start any m4
> when testing for flex. Also, it does not export the M4 variable.
> My best guess is that
> 1. M4 is for some reason exported into the environment before configure
> is started.
> 2. The value is then changed by configure.
> 3. Flex then inherits the modified value (although neither the
> documentation nor strings indicates that flex examines $M4).
> You could try adding an
> unexport M4
> to the configure script to see if that makes any interesting difference.
M4 is a configure user variable and it is supposed to be exported.
See the generated configure file, it is in ac_subst_vars. Although
the GMP_PROG_M4 respects user-set M4 variable, GMP's configure.in
doesn't respect it and override it if $found_asm != yes, which is
not what a configury should do and is wrong. The original report
at http://permalink.gmane.org/gmane.comp.lib.gmp.bugs/2114 suggests
moving M4 setting lines after AM_PROG_LEX and it seems reasonable.
(Well, AM_PROG_LEX & co can be moved before it, too, I guess.)
Can you please tell us what is wrong with the suggested solutions?
More information about the gmp-devel