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

On Thu, 16 Jul 2020 at 14:08, Zack Weinberg <[email protected]> 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 https://savannah.gnu.org/support/index.php?110269 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

https://gist.github.com/rossburton/036b93b6928e283a688d29167ce66f86

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

AC_INIT([argh], [1])
AC_PROG_LEX
AC_OUTPUT([])

> - the operating system where you observed AC_PROG_LEX to fail

Linux.

> - 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 libfl.so.2.0.0/.so.2/.so, the target sysroot has none of
those.  In Flex isn't libfl.so 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.

Ross