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
