From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id EBC0D388A827 for ; Fri, 19 Jun 2020 12:13:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org EBC0D388A827 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=eliz@gnu.org Received: from fencepost.gnu.org ([2001:470:142:3::e]:44129) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jmFta-0000ZC-48; Fri, 19 Jun 2020 08:13:22 -0400 Received: from [176.228.60.248] (port=2629 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jmFtZ-0002aF-D0; Fri, 19 Jun 2020 08:13:21 -0400 Date: Fri, 19 Jun 2020 15:13:09 +0300 Message-Id: <83tuz7xnhm.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves Cc: tom@tromey.com, tromey@adacore.com, gdb-patches@sourceware.org In-Reply-To: <0b80b7da-d9f8-d517-920d-60572134096e@redhat.com> (message from Pedro Alves on Fri, 19 Jun 2020 13:02:28 +0100) Subject: Re: [PATCH 2/3] Consistently use BFD's time References: <20200114210956.25115-1-tromey@adacore.com> <20200114210956.25115-3-tromey@adacore.com> <83wo9s4sac.fsf@gnu.org> <87k1044g1x.fsf@tromey.com> <83r1ucza8u.fsf@gnu.org> <87wo442wjq.fsf@tromey.com> <83o8pgz3lv.fsf@gnu.org> <83k104z2cb.fsf@gnu.org> <0b80b7da-d9f8-d517-920d-60572134096e@redhat.com> X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 12:13:25 -0000 > Cc: tom@tromey.com, tromey@adacore.com, gdb-patches@sourceware.org > From: Pedro Alves > Date: Fri, 19 Jun 2020 13:02:28 +0100 > > I had presented two different ways forward back when this was originally > discussed: > > [Handle different "struct stat" between GDB and BFD] > [users/palves/stat branch] > https://sourceware.org/legacy-ml/gdb-patches/2020-01/msg00608.html > > [use gnulib --avoid=largefile, let ACX_LARGEFILE handle enabling largefile support consistently > throughout the tree] > [users/palves/gnulib-largefile branch] > https://sourceware.org/legacy-ml/gdb-patches/2020-01/msg00637.html > > Back then IIRC, I was thinking that the --avoid=largefile solution > was the best one, but for some reason, the gnulib build fails with that, > which seemed like a gnulib bug. So maybe we should report the latter issue to Gnulib folks, because the --avoid=largefile solution was also proposed to me by Paul Eggert and Bruno Haible at the time: https://lists.gnu.org/archive/html/bug-gnulib/2019-12/msg00216.html > Since you then said back then you didn't really care for a solution > to this problem, I ended up forgetting about this whole issue and > many of the details. :-/ I still "don't care", in the sense that if this is only a problem for the mingw.org's MinGW build of GDB, I can solve it locally, and don't want to be the reason for the GDB development being at an impasse. I responded to Tom's message because I interpreted it as meaning that Tom was working on a problem whose effects are much wider, and because Tom explicitly asked for my opinion. IOW, I'm okay with your proposals as well, as long as they work for the affected systems. Thanks.