From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <simark@simark.ca>
Received: from simark.ca (simark.ca [158.69.221.121])
 by sourceware.org (Postfix) with ESMTPS id 7866B3842430;
 Tue, 28 Jul 2020 14:17:28 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7866B3842430
Authentication-Results: sourceware.org;
 dmarc=none (p=none dis=none) header.from=simark.ca
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca
Received: from [10.0.0.11] (173-246-6-90.qc.cable.ebox.net [173.246.6.90])
 (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits))
 (No client certificate requested)
 by simark.ca (Postfix) with ESMTPSA id 24E321E794;
 Tue, 28 Jul 2020 10:17:28 -0400 (EDT)
Subject: Re: [PATCH] Unify Solaris procfs and largefile handling
To: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Cc: binutils@sourceware.org, gdb-patches@sourceware.org
References: <yddbll0mvov.fsf@CeBiTec.Uni-Bielefeld.DE>
 <51f44a63-3062-39e5-14c5-ed08e32f2129@simark.ca>
 <yddime74ujs.fsf@CeBiTec.Uni-Bielefeld.DE>
From: Simon Marchi <simark@simark.ca>
Message-ID: <5aae580e-ab2e-f008-91c6-f3b1c1f757b7@simark.ca>
Date: Tue, 28 Jul 2020 10:17:22 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <yddime74ujs.fsf@CeBiTec.Uni-Bielefeld.DE>
Content-Type: text/plain; charset=utf-8
Content-Language: fr
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
 SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: gdb-patches@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gdb-patches mailing list <gdb-patches.sourceware.org>
List-Unsubscribe: <http://sourceware.org/mailman/options/gdb-patches>,
 <mailto:gdb-patches-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-request@sourceware.org?subject=help>
List-Subscribe: <http://sourceware.org/mailman/listinfo/gdb-patches>,
 <mailto:gdb-patches-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jul 2020 14:17:29 -0000

On 2020-07-28 9:51 a.m., Rainer Orth wrote:
> Unfortunately not: <sys/procfs.h> is sometimes used in code shared with
> non-Solaris systems, none of which have <procfs.h>.  So we'd have to
> conditionalize on HAVE_PROCFS_H vs. HAVE_SYS_PROCFS_H.
> 
> And on older Solaris 11.3, even when using the new procfs interface,
> <sys/procfs.h> errors out when largefile support is enabled.
> 
> As I said: it's a royal mess ;-(
> 
> 	Rainer

Ok, I see.

The only part I'm not sure about is the part that adds --enable-gdb to all configure
files.  For example we now have this in bfd's configure:

$ ./binutils/configure --help | grep gdb
  --enable-gdb[=ARG]     build gdb [ARG={yes,no}]

I understand that you want to catch whether the user enabled or disabled building GDB
with --enable-gdb or --disable-gdb, but the result is a bit weird.  Is there a way not
to include it in the --help?

Ideally, the top-level configure system would be able to tell which modules are enabled.
I don't know much about it, maybe there's a way.

In your patch, can

  : ${enable_largefile="no"}

become just

  enable_largefile="no"

?

Simon