From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-sender-0.a4lg.com (mail-sender.a4lg.com [153.120.152.154]) by sourceware.org (Postfix) with ESMTPS id C61D1385841F for ; Tue, 25 Oct 2022 05:53:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C61D1385841F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=irq.a4lg.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=irq.a4lg.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail-sender-0.a4lg.com (Postfix) with ESMTPSA id 315E6300089; Tue, 25 Oct 2022 05:53:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=irq.a4lg.com; s=2017s01; t=1666677188; bh=zHkkReXPjAO5UQaaushb01hN7AqKUs9hNaRGYgrvOrw=; h=Message-ID:Date:Mime-Version:Subject:From:To:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=aEvfVQW20xMumkFaQ5XT9wNZCVjsN+GdEPxAOMLpZA3J1TJ6FKbg2MbGeLDCkuHwo 2LP4unuQnSlPxK3Et178p1eMkQyAIkeqBMuLKKPEWxjGk9Etndam9XzxDErk8mQcby haDbnrb1clyaY96N/tMpPVbiedU/R3ljVNdoJE2c= Message-ID: Date: Tue, 25 Oct 2022 14:53:06 +0900 Mime-Version: 1.0 Subject: Re: [PATCH] sim, sim/m32c, sim/rl78: Use getopt_long From: Tsukasa OI To: Tom Tromey , gdb-patches@sourceware.org References: <3b7e769f-b5e9-4049-786f-d00d997f0280@irq.a4lg.com> <24e83e920d728237c4efe6f4720643d6fbbf1084.1666113214.git.research_trasio@irq.a4lg.com> <87sfjhb0r5.fsf@tromey.com> <2024f524-35e3-cdc6-8098-a220daf30c23@irq.a4lg.com> Content-Language: en-US In-Reply-To: <2024f524-35e3-cdc6-8098-a220daf30c23@irq.a4lg.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2022/10/24 16:51, Tsukasa OI wrote: > On 2022/10/22 1:27, Tom Tromey wrote: >>>>>>> Tsukasa OI via Gdb-patches writes: >> >>> Because of Binutils/GCC hack, getopt on GNU libc (2.25 or before) is >>> currently unusable on sim, causing a regression on CentOS 7. Getting rid of >>> include/getopt.h is the best solution to avoid hacking >> >> I don't think we want to do remove this file. getopt_long is required >> by a bunch of programs in the tree, and is part of libiberty -- but it's >> not in the traditional getopt.h. >> >> Using getopt_long seems like an improvement though. > > Glibc (2.25 or before; not too old to drop support) includes > from but this causes to include Binutils/GCC's > include/getopt.h. It means, using the filename "getopt.h" in an include > path (-I) itself is a risk. The only reason it didn't cause a problem > is most of Binutils/GCC components used getopt_long and > getopt_long_only, not plain getopt. > > After I started checking getopt in sim/configure (to reduce build > failure on Clang), it became a problem on sim because some sim files > actually use plain getopt. > > c.f. Following thread under binutils > > >> >>> but as a short-term >>> solution, this commit replaces calls to getopt to call getopt_long. >> >> I notice you didn't update sim/ppc... why is that? > > Because I simply missed that (I grepped "getopt (" and two occurrences > under sim/ppc uses "getopt(" without space between "getopt" and "(" ). > > Thanks for spotting that and I'll fix it soon. > > Thanks, > Tsukasa There was another reason (I should have tested the branch before submission and I wondered why I missed those getopt calls): for sim/ppc files, it includes before including project's config.h, making getopt declarations not suppressed. Replacing getopt with getopt_long will make this fact not relevant and I'll just replace the function without modifying #include order (that should be handled as a part of future "build with Clang" patchset). Regards, Tsukasa > >> If those don't have the problem then perhaps we can just use that >> solution, whatever it is. >> >> Tom >>