[sr #110312] 2.69b: broken AC_PROG_LEX macro

[Zack Weinberg]

Update of sr #110312 (project autoconf):

  Status:   Need Info => Works For Me   
 Open/Closed:Open => Closed 

___

Follow-up Comment #12:

Since we haven't heard anything from Tomasz in more than a month, and several
changes have been made that _should_ have addressed this problem, I am going
to go ahead and close this bug.  Tomasz, if you can still reproduce the
problem with 2.69d please feel free to reopen and provide more details.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110312] 2.69b: broken AC_PROG_LEX macro

[Zack Weinberg]

Follow-up Comment #11, sr #110312 (project autoconf):

That's unfortunate.  I agree we really need Tomasz's input to make any further
progress here.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110312] 2.69b: broken AC_PROG_LEX macro

[Jannick]

Follow-up Comment #10, sr #110312 (project autoconf):

@Zack: I cannot reproduce the issue either. For both autoconf 2.69 and 2.69b
the tiny configure.ac below yields (wih flex 2.6.4): 

checking for flex... flex
checking for lex output file root... lex.yy
checking for lex library... -lfl
checking whether yytext is a pointer... yes


For autoconf 2.69d:

checking for flex... flex
checking for lex output file root... lex.yy
checking for lex library... none needed
checking for library containing yywrap... -lfl
checking whether yytext is a pointer... yes

Anything I can do? I guess it would be best to get the config.logs from
Tomasz's runs for autoconf 2.69 and 2.69b to see what was happening. 

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110312] 2.69b: broken AC_PROG_LEX macro

[Zack Weinberg]

Follow-up Comment #9, sr #110312 (project autoconf):

I've gone ahead and applied Jannick's suggested change (commit
15ada9d3a0e46c28c0a3af2357b64bbd14d818a8), since I don't see any way it could
_hurt_, but I do not understand why it makes a difference, and I still can't
reproduce the original problem on my computer.  Before I call this bug "fixed"
I want to understand what the original problem was and why the changes we've
made actually fix it.

@Jannick Can you reproduce the original problem?  If so, can you go into
detail about the conditions where it happens?  Information that might be
relevant includes:

 - a minimal configure.ac that reproduces the problem, if that's different
from the one that I said didn't reproduce it for me
 - the config.log from a run that reproduces the problem
 - the git commit hash for the version of autoconf used to reproduce the
problem
 - whether the problem can still be reproduced with autoconf built from git
commit 15ada9d3a0e46c28c0a3af2357b64bbd14d818a8
 - whether you have flex or classic lex, its exact version number, and whether
redistributors have applied their own patches
 - the config.guess triplet for the OS where you could reproduce the problem
 - the "distribution" of the OS, if there is such a thing and it's not named
in the config.guess triplet
 - the output of `find /lib /usr \( -name libl.* -o -name libfl.* \) -ls 2>
/dev/null`
 - the output of `cc -print-search-dirs`

Thanks in advance for your help.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110312] 2.69b: broken AC_PROG_LEX macro

[Jannick]

Follow-up Comment #8, sr #110312 (project autoconf):

In order to mimic flex's '%option noyywrap', the generated scanner code
(inserted between the first and second %%) needs a declaration (or definition)
of yywrap _before_ the first %%:

Applying

 
diff --git a/lib/autoconf/programs.m4 b/lib/autoconf/programs.m4
index e289a018..b352ce24 100644
--- a/lib/autoconf/programs.m4
+++ b/lib/autoconf/programs.m4
@@ -746,6 +746,9 @@ fi])])
 # declares yytext as a char * by default.
 AC_DEFUN([_AC_PROG_LEX_YYTEXT_DECL],
 [cat >conftest.l <<_ACEOF[
+%{
+int yywrap(void);
+%}
 %%
 a { ECHO; }
 b { REJECT; }

to

$ git describe
v2.69c-18-gf1047b2e 

(NB: this excludes the commit 46f384f850, 'Revert to 2.69-compatible behavior
in AC_PROG_LEX') 

makes configure print (for Zack's test configure.ac below)

checking for lex output file root... lex.yy
checking for lex library... none needed
checking whether yytext is a pointer... yes


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110312] 2.69b: broken AC_PROG_LEX macro

[Zack Weinberg]

Update of sr #110312 (project autoconf):

  Status:None => Need Info  

___

Follow-up Comment #7:

I cannot reproduce the problem with this configure.ac:


AC_INIT([bug-110312], [1.0])
AC_PROG_LEX
AC_OUTPUT


It prints "checking for lex library... none needed" regardless of whether
libl.a or libfl.so is present on the system.  In fact, it says the same thing
even if *none* of the lib{f,}l.* files that my system usually has are
available.  There must be something else going on.

I'm going to need that minimal configure.ac I asked for on Thursday, and I'm
also going to need the config.log produced when you run it on your system.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110312] 2.69b: broken AC_PROG_LEX macro

[Zack Weinberg]

Follow-up Comment #6, sr #110312 (project autoconf):

Thanks.  I understand how your system is set up now, I think.

I still need that minimal configure.ac that reproduces the behavior to make
any progress.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110312] 2.69b: broken AC_PROG_LEX macro

[Tomasz Kłoczko]

Follow-up Comment #5, sr #110312 (project autoconf):


[comment #3 comment #3:]
> The output of these commands would also be really helpful:
> 
> nm --defined-only /usr/lib64/libfl.a
> nm --dynamic --defined-only /usr/lib64/libfl.so

[root@barrel SRPMS]# nm --defined-only /usr/lib64/libfl.a

libmain.o:
 T main

libyywrap.o:
 T yywrap


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110312] 2.69b: broken AC_PROG_LEX macro

[Tomasz Kłoczko]

Follow-up Comment #4, sr #110312 (project autoconf):


[comment #2 comment #2:]
> Could you please construct and send us a minimal configure.ac that
reproduces this behavior?  Also, it would be helpful to see the output of 
> 
> find /lib /usr \( -name 'libl.*' -o -name 'libfl.*' \) -ls

[root@barrel SRPMS]# find /lib /usr \( -name 'libl.*' -o -name 'libfl.*' \)
-ls
  7281276 24 -rw-r--r--   1 root root21270 Sep 15 20:57
/usr/lib64/libfl.a


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110312] 2.69b: broken AC_PROG_LEX macro

[Zack Weinberg]

Follow-up Comment #3, sr #110312 (project autoconf):

The output of these commands would also be really helpful:

nm --defined-only /usr/lib64/libfl.a
nm --dynamic --defined-only /usr/lib64/libfl.so

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110312] 2.69b: broken AC_PROG_LEX macro

[Zack Weinberg]

Follow-up Comment #2, sr #110312 (project autoconf):

Could you please construct and send us a minimal configure.ac that reproduces
this behavior?  Also, it would be helpful to see the output of 

find /lib /usr \( -name 'libl.*' -o -name 'libfl.*' \) -ls

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110312] 2.69b: broken AC_PROG_LEX macro

[Tomasz Kłoczko]

Follow-up Comment #1, sr #110312 (project autoconf):

Actually seems like I'm a bit wrong. After roll back to autoconf 2.69 the same
looks a bit different:

```
checking for flex... flex
checking lex output file root... lex.yy
checking lex library... none needed
```


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110312] 2.69b: broken AC_PROG_LEX macro

[Tomasz Kłoczko]

URL:
  

 Summary: 2.69b: broken AC_PROG_LEX macro
 Project: Autoconf
Submitted by: kloczek
Submitted on: Tue 15 Sep 2020 08:14:18 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

Looks like AC_PROG_LEX on testing is trying to link with liblex and on that it
fails when GNU flex is installed:

```
checking for flex... flex
checking for lex output file root... lex.yy
checking for lex library... not found
configure: error: required lex library not found
```
All because glu flex provides only libfl.

$ rpm -ql flex| grep lib64
/usr/lib64/libfl.a





___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/