[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Revert 'Fix logic error in _AC_PROG_LEX_YYTEXT_DECL (#109320

From: Ross Burton
Subject: Re: [PATCH] Revert 'Fix logic error in _AC_PROG_LEX_YYTEXT_DECL (#109320)'
Date: Thu, 16 Jul 2020 14:46:01 +0100

On Thu, 16 Jul 2020 at 14:08, Zack Weinberg <> wrote:
> > Commit 8173e5, 'Fix logic error in _AC_PROG_LEX_YYTEXT_DECL (#109320)',
> > causes AC_PROG_LEX to always fail when searching for a lex library.
> Before we give up on this patch I'd like to understand the conditions
> under which it fails.

Agreed.  I admit that the revert was a way of getting attention, I
filed a bug at with
further details.

> I did test it extensively on my computer, with
> several different permutations of libl.{a,so} and libfl.{a,so}
> available.  It would help if you could tell me as much as possible of
> the following:
> - the config.log from a configure invocation where AC_PROG_LEX failed

> - where I can find the from which that configure script
> was generated

AC_INIT([argh], [1])

> - the operating system where you observed AC_PROG_LEX to fail


> - the shell used to execute the configure script

The script was executed in a bash.

> - whether you have original lex or flex or both, and the versions of each
> - the output of `find /usr \( -name libl\* -o -name libfl\* \) -ls`

I'm in a cross-compiling environment.  The native sysroot has the flex
binary and, the target sysroot has none of
those.  In Flex isn't only needed if you want to turn a
generated parser into a stand-alone binary for testing?

I'm about to dive into another meeting but I'm guessing this is cause
of the problem.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]