mainAutoconf - Support: sr #110312, 2.69b: broken AC_PROG_LEX macro

 
 

sr #110312: 2.69b: broken AC_PROG_LEX macro

Submitter:  Tomasz Kłoczko <kloczek>
Submitted:  Tue 15 Sep 2020 08:14:18 PM UTC
   
 
Priority:  * 5 - Unprioritized Severity:  3 - Normal
Status:  Works For Me Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Operating System:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 15 Nov 2020 08:24:19 PM UTC, 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.

Zack Weinberg <zackw>
Group administrator
Wed 04 Nov 2020 03:01:26 PM UTC, comment #11: 

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

Zack Weinberg <zackw>
Group administrator
Wed 04 Nov 2020 02:37:54 PM UTC, comment #10: 

@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.

Jannick <jannick>
Tue 03 Nov 2020 03:23:13 PM UTC, comment #9: 

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.

Zack Weinberg <zackw>
Group administrator
Tue 03 Nov 2020 09:13:29 AM UTC, comment #8: 

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


Jannick <jannick>
Sat 26 Sep 2020 05:53:07 PM UTC, 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.

Zack Weinberg <zackw>
Group administrator
Thu 24 Sep 2020 08:46:28 PM UTC, comment #6: 

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.

Zack Weinberg <zackw>
Group administrator
Thu 24 Sep 2020 06:17:11 PM UTC, comment #5: 


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:
00000000 T main

libyywrap.o:
00000000 T yywrap

Tomasz Kłoczko <kloczek>
Thu 24 Sep 2020 06:15:05 PM UTC, comment #4: 


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     root        21270 Sep 15 20:57 /usr/lib64/libfl.a

Tomasz Kłoczko <kloczek>
Thu 24 Sep 2020 06:14:56 PM UTC, 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

Zack Weinberg <zackw>
Group administrator
Thu 24 Sep 2020 06:13:20 PM UTC, 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

Zack Weinberg <zackw>
Group administrator
Tue 15 Sep 2020 08:20:15 PM UTC, comment #1: 

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
```

Tomasz Kłoczko <kloczek>
Tue 15 Sep 2020 08:14:18 PM UTC, original submission:  

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

Tomasz Kłoczko <kloczek>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jannick (Posted a comment)
  • -email is unavailable- added by zackw (Posted a comment)
  • -email is unavailable- added by kloczek (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-11-15 zackw StatusNeed Info Works For Me
        Open/ClosedOpen Closed
    2020-09-26 zackw StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code