I just tested current master and we're working again:
checking for flex... flex
checking for lex output file root... lex.yy
checking for lex library... none needed
checking whether yytext is a pointer... yes
Sorted.
Is it time that autoconf gets some CI to actually exercise all these
paths?
On 7/16/20 6:36 PM, Zack Weinberg wrote:
Shouldn't this be LIBS="$ac_cv_lib_lex $ac_save_LIBS" now?
Indeed it should. Good catch, especially since this code is not likely to be
executed by anybody. Also, there was an unnecessary assignment to ac_cv_lib_lex
before the for-loop. I fixed both
On Thu, Jul 16, 2020 at 8:50 PM Paul Eggert wrote:
> On 7/16/20 11:40 AM, Zack Weinberg wrote:
> > I believe that what's in trunk now should work fine for
> > cross-compilation of programs that don't require yywrap
>
> I thought so too, but after eyeballing the trunk a bit I noticed a shell
>
On 7/16/20 11:40 AM, Zack Weinberg wrote:
I believe that what's in trunk now should work fine for
cross-compilation of programs that don't require yywrap
I thought so too, but after eyeballing the trunk a bit I noticed a shell
portability bug in the recently-added AC_PROG_LEX code. I then
On 7/16/20 12:42 PM, Ross Burton wrote:
checking for flex... flex
checking for lex output file root... lex.yy
checking for lex library... not found
configure: WARNING: required lex library not found; giving up on flex
...
configure: error: readline works only with flex.
Again, bc's scanner has
Building bc:
checking for flex... flex
checking for lex output file root... lex.yy
checking for lex library... not found
configure: WARNING: required lex library not found; giving up on flex
...
configure: error: readline works only with flex.
Again, bc's scanner has its own yywrap
On Thu, Jul 16, 2020 at 2:47 PM Ross Burton wrote:
> On Thu, 16 Jul 2020 at 19:41, Zack Weinberg wrote:
> > Can we slow down a bit please? I had written out a patch (basically
> > equivalent to what's now in trunk) and I am in the process of setting
> > up a cross-compilation environment to
On Thu, 16 Jul 2020 at 19:41, Zack Weinberg wrote:
> Can we slow down a bit please? I had written out a patch (basically
> equivalent to what's now in trunk) and I am in the process of setting
> up a cross-compilation environment to validate the fix for certain,
> but this is going to take
On Thu, Jul 16, 2020 at 1:55 PM Ross Burton wrote:
> On Thu, 16 Jul 2020 at 18:51, Paul Eggert wrote:
>>
>> On 7/16/20 10:34 AM, Ross Burton wrote:
>> > Wouldn't that break cross-compilation where a host flex is present but
>> > target libfl isn't? That case worked previously and should work
I suggest you revert and take my patch. :)
I can’t actually find any projects that need libfl.so so this will continue
to break all cross compilation where a target flex isn’t around. All the
packages that I found to break were building from tarballs as they don’t
distribute the generated
On Thu, 16 Jul 2020 at 18:16, Paul Eggert wrote:
> The patch I installed was simpler and more conservative than what you
> proposed.
> It gives up on 'flex' and sets LEX back to ":" if any of the
> _AC_PROG_LEX_YYTEXT_DECL tests fail.
Wouldn't that break cross-compilation where a host flex is
On 7/16/20 7:10 AM, Zack Weinberg wrote:
I propose to make the following additional changes, instead of reverting
the patch:
- Change the conftest.l used by _AC_PROG_LEX_YYTEXT_DECL so that it
defines yywrap itself (it already defines main). Thus, LEXLIB will
only be set to -ll or -lfl if
On Thu, 16 Jul 2020 at 15:19, Ross Burton wrote:
> > - Change the conftest.l used by _AC_PROG_LEX_YYTEXT_DECL so that it
> > defines yywrap itself (it already defines main). Thus, LEXLIB will
> > only be set to -ll or -lfl if there's something in there *besides*
> > yywrap and main that the
On Thu, 16 Jul 2020 at 15:10, Zack Weinberg wrote:
> I presume that gdbm, flex, and gmp provide a definition of yywrap
> themselves, so they don't actually *need* lib{,f}l.a.
gmp calclex.l:
yywrap ()
{
return 1;
}
flex scan.l:
int yywrap(void)
{
if ( --num_input_files > 0 )
On Thu, Jul 16, 2020 at 9:46 AM Ross Burton wrote:
>
> 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
On Thu, Jul 16, 2020 at 7:21 AM Ross Burton 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. I did
From: Ross Burton
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.
---
lib/autoconf/programs.m4 | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git
17 matches
Mail list logo
