This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Update gnulib to current upstream master
- From: Pedro Alves <palves at redhat dot com>
- To: Sergio Durigan Junior <sergiodj at redhat dot com>, GDB Patches <gdb-patches at sourceware dot org>
- Date: Wed, 29 Aug 2018 20:06:27 +0100
- Subject: Re: [PATCH] Update gnulib to current upstream master
- References: <87bm9mnty0.fsf@redhat.com>
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