include: Declare getopt function on old GNU libc

  On GNU libc <= 2.25, <unistd.h> includes <getopt.h> with __need_getopt macro
defined.  That <getopt.h> is intended to be a part of GNU libc but
<unistd.h> actually includes include/getopt.h in this project.

If HAVE_DECL_GETOPT is defined to 1 and include/getopt.h is included from
GNU libc's <unistd.h>, declaration of getopt is suppressed, causing errors
on getopt callers.  This issue is possibly hidden so long because there are
not so many true getopt callers in Binutils, GDB and GCC.  Still, this issue
needs to be fixed for following components:

-   Binutils: gprofng
    (not currently affected due to the configuration script but will be)
-   GDB (sim): M32C simulator
-   GDB (sim): RL78 simulator

To avoid not defining proper getopt declaration, we have to check
__need_getopt macro to detect this include path.  With this commit, even if
HAVE_DECL_GETOPT is 1, getopt is declared if:

-   The standard C library is GNU libc and
-   __need_getopt macro is defined (<unistd.h> includes <getopt.h> to
    declare getopt function).

include/ChangeLog:

	* getopt.h: Detect special include path on GNU libc 2.25 or older
	to prevent not declaring getopt function when necessary.
---
 include/getopt.h | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)


base-commit: 927b2f4caf46e5ca49684c9a52a9786425c60fa2
  

On 2022-10-13 11:11 a.m., Tsukasa OI via Binutils wrote:
> On GNU libc <= 2.25, <unistd.h> includes <getopt.h> with __need_getopt macro
> defined.  That <getopt.h> is intended to be a part of GNU libc but
> <unistd.h> actually includes include/getopt.h in this project.

Messy.

Do we really still need this getopt.h header?

gnulib, at:

 https://www.gnu.org/software/gnulib/manual/html_node/getopt_002eh.html

says:

  "This header file is missing on some platforms: AIX 5.1, HP-UX 11, MSVC 14."

AIX 5.1 is from 2001.
HP-UX 11 is from 1997.
We don't support building with MSVC AFAIK.

Can't we just get rid of it?
  

On 10/13/22 12:11, Tsukasa OI wrote:
> On GNU libc <= 2.25, <unistd.h> includes <getopt.h> with __need_getopt macro
> defined.  That <getopt.h> is intended to be a part of GNU libc but
> <unistd.h> actually includes include/getopt.h in this project.
> 
> If HAVE_DECL_GETOPT is defined to 1 and include/getopt.h is included from
> GNU libc's <unistd.h>, declaration of getopt is suppressed, causing errors
> on getopt callers.  This issue is possibly hidden so long because there are
> not so many true getopt callers in Binutils, GDB and GCC.  Still, this issue
> needs to be fixed for following components:
> 
> -   Binutils: gprofng
>      (not currently affected due to the configuration script but will be)
> -   GDB (sim): M32C simulator
> -   GDB (sim): RL78 simulator
> 
> To avoid not defining proper getopt declaration, we have to check
> __need_getopt macro to detect this include path.  With this commit, even if
> HAVE_DECL_GETOPT is 1, getopt is declared if:
> 
> -   The standard C library is GNU libc and
> -   __need_getopt macro is defined (<unistd.h> includes <getopt.h> to
>      declare getopt function).
> 

I've put this into the gdb try-buildbot, and it fixes the centos 
regression : 
https://builder.sourceware.org/buildbot/#/builders/118/builds/17 .

I didn't get emails to that effect for some reason, but visual 
inspection at https://builder.sourceware.org/ of the try build bots at 
gdb shows all green.

Thanks,
- Tom

> include/ChangeLog:
> 
> 	* getopt.h: Detect special include path on GNU libc 2.25 or older
> 	to prevent not declaring getopt function when necessary.
> ---
>   include/getopt.h | 9 ++++++++-
>   1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/include/getopt.h b/include/getopt.h
> index d8103f97483..e941b811ace 100644
> --- a/include/getopt.h
> +++ b/include/getopt.h
> @@ -104,7 +104,14 @@ struct option
>      declaration without arguments.  If it is 0, we checked and failed
>      to find the declaration so provide a fully prototyped one.  If it
>      is 1, we found it so don't provide any declaration at all.  */
> -#if !HAVE_DECL_GETOPT
> +/* On GNU libc <= 2,25, <unistd.h> includes <getopt.h> with __need_getopt
> +   macro defined.  That <getopt.h> is intended to be a part of GNU libc
> +   but <unistd.h> actually includes THIS getopt.h.  If HAVE_DECL_GETOPT is
> +   defined to 1 and this file is included from GNU libc's <unistd.h>,
> +   declaration of getopt is suppressed, causing errors on getopt callers.
> +   To avoid not defining proper getopt declaration, we have to check
> +   __need_getopt macro when built with GNU libc to detect this include path.  */
> +#if !HAVE_DECL_GETOPT || (defined (__GNU_LIBRARY__) && defined (__need_getopt))
>   #if defined (__GNU_LIBRARY__) || defined (HAVE_DECL_GETOPT)
>   /* Many other libraries have conflicting prototypes for getopt, with
>      differences in the consts, in unistd.h.  To avoid compilation
> 
> base-commit: 927b2f4caf46e5ca49684c9a52a9786425c60fa2
  

On 2022/10/13 20:59, Pedro Alves wrote:
> On 2022-10-13 11:11 a.m., Tsukasa OI via Binutils wrote:
>> On GNU libc <= 2.25, <unistd.h> includes <getopt.h> with __need_getopt macro
>> defined.  That <getopt.h> is intended to be a part of GNU libc but
>> <unistd.h> actually includes include/getopt.h in this project.
> 
> Messy.

Well, I have to agree.

> 
> Do we really still need this getopt.h header?
> 
> gnulib, at:
> 
>  https://www.gnu.org/software/gnulib/manual/html_node/getopt_002eh.html
> 
> says:
> 
>   "This header file is missing on some platforms: AIX 5.1, HP-UX 11, MSVC 14."
> 
> AIX 5.1 is from 2001.
> HP-UX 11 is from 1997.
> We don't support building with MSVC AFAIK.
> 
> Can't we just get rid of it?
> 

I feel this is too unsafe to do that (unless you assume getopt_long and
getopt_long_only are always available on the system).

Even if this patch is unacceptable, I don't want to revert previous
changes to sim/configure{,.ac} either (it's necessary to prevent a build
failure with Clang).  It's also a hack but to stop using getopt
(entirely) may be an option, changing following files:

-   sim/igen/igen.c
-   sim/m32c/main.c
-   sim/rl78/main.c

I mean, we could replace getopt with getopt_long plus dummy longopts.
This way, CentOS (7) regression will (also) be gone.

What do you think?

Thanks,
Tsukasa
  

On 2022-10-16 2:12 p.m., Tsukasa OI wrote:
> On 2022/10/13 20:59, Pedro Alves wrote:
>> On 2022-10-13 11:11 a.m., Tsukasa OI via Binutils wrote:
>>> On GNU libc <= 2.25, <unistd.h> includes <getopt.h> with __need_getopt macro
>>> defined.  That <getopt.h> is intended to be a part of GNU libc but
>>> <unistd.h> actually includes include/getopt.h in this project.
>>
>> Messy.
> 
> Well, I have to agree.
> 
>>
>> Do we really still need this getopt.h header?
>>
>> gnulib, at:
>>
>>  https://www.gnu.org/software/gnulib/manual/html_node/getopt_002eh.html
>>
>> says:
>>
>>   "This header file is missing on some platforms: AIX 5.1, HP-UX 11, MSVC 14."
>>
>> AIX 5.1 is from 2001.
>> HP-UX 11 is from 1997.
>> We don't support building with MSVC AFAIK.
>>
>> Can't we just get rid of it?
>>
> 
> I feel this is too unsafe to do that

Why?  Are you aware of any host system that people actually build binutils on
that doesn't have a proper getopt declaration?

> (unless you assume getopt_long and
> getopt_long_only are always available on the system).

getopt is supposed to be declared in unistd.h.  The .c files that
use getopt (not the GNU extensions) could just switch to including
that one.

Even if there is such a system, I would think that a better fix would
be to rename include/getopt.h to something else, and have that header include
<getopt.h> and/or do whatever else needed to pick the right declarations on the system.
A standard header replacement that doesn't #include_next the original is just asking
for trouble, like we've run into...

> 
> Even if this patch is unacceptable, I don't want to revert previous
> changes to sim/configure{,.ac} either (it's necessary to prevent a build
> failure with Clang).  

It's only necessary because of this hacky include/getopt.h header existing, no?.
Why would you want to keep the configure.ac bits if the hacky header with the
unprototyped declaration doesn't exist any more?

Thanks,
Pedro Alves

> It's also a hack but to stop using getopt
> (entirely) may be an option, changing following files:
> 
> -   sim/igen/igen.c
> -   sim/m32c/main.c
> -   sim/rl78/main.c
> 
> I mean, we could replace getopt with getopt_long plus dummy longopts.
> This way, CentOS (7) regression will (also) be gone.
> 
> What do you think?
> 
> Thanks,
> Tsukasa
>
  

On 2022/10/17 20:52, Pedro Alves wrote:
> On 2022-10-16 2:12 p.m., Tsukasa OI wrote:
>> On 2022/10/13 20:59, Pedro Alves wrote:
>>> On 2022-10-13 11:11 a.m., Tsukasa OI via Binutils wrote:
>>>> On GNU libc <= 2.25, <unistd.h> includes <getopt.h> with __need_getopt macro
>>>> defined.  That <getopt.h> is intended to be a part of GNU libc but
>>>> <unistd.h> actually includes include/getopt.h in this project.
>>>
>>> Messy.
>>
>> Well, I have to agree.
>>
>>>
>>> Do we really still need this getopt.h header?
>>>
>>> gnulib, at:
>>>
>>>  https://www.gnu.org/software/gnulib/manual/html_node/getopt_002eh.html
>>>
>>> says:
>>>
>>>   "This header file is missing on some platforms: AIX 5.1, HP-UX 11, MSVC 14."
>>>
>>> AIX 5.1 is from 2001.
>>> HP-UX 11 is from 1997.
>>> We don't support building with MSVC AFAIK.
>>>
>>> Can't we just get rid of it?
>>>
>>
>> I feel this is too unsafe to do that
> 
> Why?  Are you aware of any host system that people actually build binutils on
> that doesn't have a proper getopt declaration?

No.  I'm worrying because currently included getopt.h contains
declarations of getopt_long and getopt_long_only.  Those declarations
are required (not necessarily in <getopt.h> though) because if the
system does not have getopt_long and/or getopt_long_only, libiberty
implementation is (and should be) used.

>> (unless you assume getopt_long and
>> getopt_long_only are always available on the system).

That's why I said the sentence above.

> 
> getopt is supposed to be declared in unistd.h.  The .c files that
> use getopt (not the GNU extensions) could just switch to including
> that one.
> 
> Even if there is such a system, I would think that a better fix would
> be to rename include/getopt.h to something else, and have that header include
> <getopt.h> and/or do whatever else needed to pick the right declarations on the system.
> A standard header replacement that doesn't #include_next the original is just asking
> for trouble, like we've run into...

I also agree that.  In fact, that was my first idea to deal with this
problem.  As a long-term solution, I support your idea.

But, as a short-term solution, there are a few obstacles and intentions:

1.  The fact that include/getopt.h is shared by both Binutils and GCC
    projects so that we must sync Binutils and GCC.
    That would be far beyond my capacity to handle.  My messy patch also
    changed include/getopt.h but I thought I can explain the changes
    to GCC people (since the changes were that small).
2.  I don't want to disrupt any release schedule.  The changes will not
    be small and spans through multiple subprojects.
3.  For me, it's fine as long as...
    a.  CentOS 7 regression is resolved and
    b.  Build problem with Clang is fewer than before

Replacing getopt with getopt_long won't be large and relatively
self-explanatory.  I will propose sim workaround as a short-term solution.
_At the same time_, we could discuss the possibility of getting rid of
"include/getopt.h" entirely.

Thanks,
Tsukasa

> 
>>
>> Even if this patch is unacceptable, I don't want to revert previous
>> changes to sim/configure{,.ac} either (it's necessary to prevent a build
>> failure with Clang).  
> 
> It's only necessary because of this hacky include/getopt.h header existing, no?.
> Why would you want to keep the configure.ac bits if the hacky header with the
> unprototyped declaration doesn't exist any more?
> 
> Thanks,
> Pedro Alves
> 
>> It's also a hack but to stop using getopt
>> (entirely) may be an option, changing following files:
>>
>> -   sim/igen/igen.c
>> -   sim/m32c/main.c
>> -   sim/rl78/main.c
>>
>> I mean, we could replace getopt with getopt_long plus dummy longopts.
>> This way, CentOS (7) regression will (also) be gone.
>>
>> What do you think?
>>
>> Thanks,
>> Tsukasa
>>
>