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
From: Ross Burton
Most users of flex provide their own implementation of yywrap instead of
linking to libfl.so, which simply provides stub main() and yywrap()
implementations.
However the recent change 'Fix logic error in _AC_PROG_LEX_YYTEXT_DECL
(#109320)' means that the flex tool being
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
16 matches
Mail list logo
