Bug 2137515

(In reply to Florian Weimer from comment #0)
> I tried building automake-1.16.5-9.fc38.
> 
> I see a bunch of compiler errors in the automake testsuite. Most of them are
> implicit function declarations:
> 
> gcc -DPACKAGE_NAME=\"lex-multiple\" -DPACKAGE_TARNAME=\"lex-multiple\"
> -DPACKAGE_VERSION=\"1.0\" -DPACKAGE_STRING=\"lex-multiple\ 1.0\"
> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"lex-multiple\"
> -DVERSION=\"1.0\" -DYYTEXT_POINTER=1 -I.     -O2 -flto=auto
> -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall
> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -MT
> main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.c
> main.c: In function 'main':
> main.c:10:13: error: implicit declaration of function 'yylex'
>    10 |     return (yylex () != 121);
>       |             ^~~~~
> main.c:12:13: error: implicit declaration of function 'foolex'
>    12 |     return (foolex () != 121);
>       |             ^~~~~~
> main.c:14:13: error: implicit declaration of function 'bar_lex'
>    14 |     return (bar_lex () != 121);
>       |             ^~~~~~~
> […]
> FAIL t/lex-multiple.sh (exit status: 2)
> FAIL: t/lex-noyywrap

These failures are weird, the "{yy,foo,bar_}lex" functions should be generated by flex on the fly, and therefore declared by it. Which would mean this issue would come from Flex, not automake.

Well, main.c looks like this as far as I can tell:

cat > main.c << 'END'
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main (int argc, char *argv[])
{
  if (argc != 2)
    abort ();
  else if (!strcmp(argv[1], "--vanilla"))
    return (yylex () != 121);
  else if (!strcmp(argv[1], "--foo"))
    return (foolex () != 121);
  else if (!strcmp(argv[1], "--bar"))
    return (bar_lex () != 121);
  else
    abort ();
}
END

So if a header file is created (see flex --header-file=), it is not used. This looks like an issue with the automake test code.

(In reply to Florian Weimer from comment #2)
> So if a header file is created (see flex --header-file=), it is not used.

Indeed I missed that, sorry :(.

So, in principle, I'll likely go for "in place" declaration, instead of creating a header from flex.
The rational is that checking for the header creation is part of a dedicated test, and using the feature is a bit more intrusive than having an "extern" declaration just above the main function.

Anyway, some of the errors are a bit more annoying:

joe.c: In function 'yy_init_buffer':
joe.c:1319:40: error: implicit declaration of function 'isatty'
 1319 | 
      |                                        ^    

This one is either due to Flex, or to Automake, depending how you see it.
Automake defines the following in some of the Flex tests:

%{
#define YY_NO_UNISTD_H 1
%}

Which leads to the missing declaration of 'isatty' which is used by flex.

Yet, it can be considered that Flex should properly deal with it, if it offers such an option. Or we can consider that Automake must not define it, as we may not care nowadays.

You are right, the isatty is somewhat concerning. But there should be a flex option to get rid of it:

'--always-interactive, '%option always-interactive''
     instructs flex to generate a scanner which always considers its
     input _interactive_.  Normally, on each new input file the scanner
     calls 'isatty()' in an attempt to determine whether the scanner's
     input source is interactive and thus should be read a character at
     a time.  When this option is used, however, then no such call is
     made.

'--never-interactive, '--never-interactive''
     instructs flex to generate a scanner which never considers its
     input interactive.  This is the opposite of 'always-interactive'.

The second one also has an @option never-interactive variant (fixed in later versions of the manual).

Maybe this way, you can keep the YY_NO_UNISTD_H and avoid the undeclared function?

Patches have been sent upstream, and are currently being reviewed:

https://lists.gnu.org/archive/html/automake-patches/2022-12/msg00002.html
https://lists.gnu.org/archive/html/automake-patches/2022-12/msg00005.html

Should be fixed in automake-1.16.5-12.fc39.

Hopefully I didn't miss anything. Note that there are remaining XFAIL test that have improper construct on purpose, which will trigger GCC build errors.