From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117806 invoked by alias); 29 Aug 2018 19:06:34 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 117791 invoked by uid 89); 29 Aug 2018 19:06:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=exercise, pulled X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 29 Aug 2018 19:06:32 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 81CED804B4B9 for ; Wed, 29 Aug 2018 19:06:30 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3079D63F68; Wed, 29 Aug 2018 19:06:28 +0000 (UTC) Subject: Re: [PATCH] Update gnulib to current upstream master To: Sergio Durigan Junior , GDB Patches References: <87bm9mnty0.fsf@redhat.com> From: Pedro Alves Message-ID: Date: Wed, 29 Aug 2018 19:06:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <87bm9mnty0.fsf@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-08/txt/msg00768.txt.bz2 On 08/28/2018 08:59 PM, Sergio Durigan Junior wrote: > [ Disclaimer: I'm sending the patch gzipped because I'm afraid > sourceware won't accept a 1.2MB message. ] > > It has been a while since we don't update our gnulib copy against > their upstream master branch, so I thought I'd propose this patch. It > also fixes (at least) one bug reported against GDB: > > https://sourceware.org/bugzilla/show_bug.cgi?id=23558 > > The problem reported there is about the replacement of 'getcwd' when > cross-compiling GDB. With our current gnulib copy, the mechanism for > deciding whether to use the system's 'getcwd' or gnulib's version is > too simplistic and pessimistic, so when cross-compiling we always end > up using gnulib's version, which has a limitation: it cannot handle > the situation when the parent directory doesn't have read permissions. > > This has been reported against upstream gnulib and the fix has been > pushed here: > > https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=a96d2e67052c879b1bcc5bc461722beac75fc372 > > I regtested this patch on Fedora 28 x86-64, and there were no > regressions. > > OK? It is standard practice when updating gnulib to discuss the set of modules that the exercise brings in due to module dependencies. If we're now including some more modules, that may mean that we could eliminate some older host compatibility code from gdb in favor of gnulib's and list the module dependencies explicitly in IMPORTED_GNULIB_MODULES in update-gnulib.h. Conversely, there's a chance that we were depending on some module that wasn't explicitly listed in IMPORTED_GNULIB_MODULES, and an update could remove the module by mistake. Another reason for that is that that are some modules that are problematic for us (e.g., the one that pulls in Windows's select replacement), so we need to look out for that, in case it is pulled in by a dependency. Also, if there were newer m4 files or m4 files deleted, I think we we need to update the list in gnulib/Makefile.in (aclocal_m4_deps). Should we cherry pick the getcwd fix to the 8.2 branch? Thanks, Pedro Alves