public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Sergio Durigan Junior <sergiodj@redhat.com>,
	GDB Patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Update gnulib to current upstream master
Date: Wed, 29 Aug 2018 19:06:00 -0000	[thread overview]
Message-ID: <dba64ca1-4eb4-7b0c-d662-d300102458cc@redhat.com> (raw)
In-Reply-To: <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

  parent reply	other threads:[~2018-08-29 19:06 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-28 19:59 Sergio Durigan Junior
2018-08-29 16:19 ` Tom Tromey
2018-08-29 16:29   ` Sergio Durigan Junior
2018-08-29 19:06 ` Pedro Alves [this message]
2018-08-29 19:34   ` Sergio Durigan Junior
2018-08-31 13:04     ` Pedro Alves
2018-08-30  0:04   ` Tom Tromey
2018-08-30  3:01     ` Sergio Durigan Junior
2018-08-30 15:57   ` [PATCH] Update gnulib/Makefile.in:aclocal_m4_deps Sergio Durigan Junior
2018-08-30 17:05     ` Simon Marchi
2018-08-30 20:00       ` Sergio Durigan Junior
2018-08-31  7:59         ` Joel Brobecker
2018-08-31 16:02           ` Sergio Durigan Junior
2018-08-31 11:21         ` Pedro Alves
2018-08-31 16:03           ` Sergio Durigan Junior
2018-09-02 21:21           ` [PATCH] Automatically update "aclocal_m4_deps" when updating gnulib Sergio Durigan Junior
2018-09-03 11:15             ` Pedro Alves
2018-09-03 21:18               ` Sergio Durigan Junior
2018-09-04 11:10                 ` Pedro Alves
2018-09-04 17:58                   ` Sergio Durigan Junior
  -- strict thread matches above, loose matches on Subject: below --
2016-10-12 15:17 [PATCH] Update gnulib to current upstream master Pedro Alves
2016-10-12 16:09 ` Yao Qi
2016-10-12 16:12   ` Pedro Alves
2016-10-12 16:23     ` Pedro Alves
2016-10-12 16:56       ` Eli Zaretskii
2016-10-12 17:10         ` Pedro Alves
2016-10-12 17:31           ` Eli Zaretskii
2016-10-12 16:30     ` Yao Qi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dba64ca1-4eb4-7b0c-d662-d300102458cc@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=sergiodj@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).