public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@palves.net>
To: Tsukasa OI <research_trasio@irq.a4lg.com>,
	Tom de Vries <tdevries@suse.de>
Cc: binutils@sourceware.org
Subject: Re: [PATCH] include: Declare getopt function on old GNU libc
Date: Mon, 17 Oct 2022 12:52:47 +0100	[thread overview]
Message-ID: <96f0f54e-3acd-c880-6f12-02f6d037501d@palves.net> (raw)
In-Reply-To: <fe379341-55e8-871a-3439-a4e329be0e1f@irq.a4lg.com>

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
> 


  reply	other threads:[~2022-10-17 11:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1664095312.git.research_trasio@irq.a4lg.com>
     [not found] ` <cover.1665038297.git.research_trasio@irq.a4lg.com>
     [not found]   ` <a57b2a3460064a9adc95914ba21214c8dbfc2bbf.1665038297.git.research_trasio@irq.a4lg.com>
     [not found]     ` <7b235ccb-ab2e-cba0-3015-2eae5fe6a8a4@suse.de>
2022-10-13  9:50       ` [PATCH v3 4/5] sim: Check known getopt definition existence Tsukasa OI
2022-10-13 10:11         ` [PATCH] include: Declare getopt function on old GNU libc Tsukasa OI
2022-10-13 11:59           ` Pedro Alves
2022-10-16 13:12             ` Tsukasa OI
2022-10-17 11:52               ` Pedro Alves [this message]
2022-10-18 11:33                 ` Tsukasa OI
2022-10-13 12:05           ` Tom de Vries

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=96f0f54e-3acd-c880-6f12-02f6d037501d@palves.net \
    --to=pedro@palves.net \
    --cc=binutils@sourceware.org \
    --cc=research_trasio@irq.a4lg.com \
    --cc=tdevries@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).