From: Rich Felker <dalias@aerifal.cx>
To: Romain Naour <romain.naour@smile.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Romain Naour <romain.naour@gmail.com>,
buildroot@buildroot.org, gdb-patches@sourceware.org
Subject: Re: [Buildroot] [PATCH 2/2] package/gdb: use stat() privided by the system
Date: Mon, 10 Sep 2018 22:41:00 -0000 [thread overview]
Message-ID: <20180910224128.GT1878@brightrain.aerifal.cx> (raw)
In-Reply-To: <d588888e-dccc-50c8-5a6e-9c5c46a512cb@smile.fr>
On Mon, Sep 10, 2018 at 11:20:58PM +0200, Romain Naour wrote:
> Hi Thomas,
>
> Adding the gdb-patches ml and Rich Felker in Cc.
>
> Le 10/09/2018 à 17:49, Thomas Petazzoni a écrit :
> > Hello,
> >
> > On Sun, 9 Sep 2018 18:37:50 +0200, Romain Naour wrote:
> >> Use the same workaround [1] as gnulib use to get the original
> >> definition of stat. Otherwise with musl toolchains, gnulib try to use
> >> rpl_stat which is not defined.
> >>
> >> Fixes:
> >> https://gitlab.com/free-electrons/toolchains-builder/-/jobs/95552308
> >>
> >> [1] http://git.savannah.gnu.org/cgit/gnulib.git/commit/lib/stat.c?id=c9d72f69bd201a1ab31464d91f234ea1817fe0e1
> >>
> >> Signed-off-by: Romain Naour <romain.naour@gmail.com>
> >> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> >
> > I am confused by this patch. Why do we need that? The <sys/stat.h> on
> > my system doesn't test __need_system_sys_stat_h. Is this a workaround
> > to force gnulib to not provide its own stat() replacement ?
> >
> > Why is gnulib misbehaving here ? We have tons of gnulib related hacks
> > in gdb.mk, and this start to pile up quite a bit. Why do we have all
> > those gnulib issues with gdb ? Why not with tons of other packages that
> > also use gnulib ?
>
> There are too many questions here, I can't answer.
> There are some (old) hack with coreutils like gl_cv_func_gettimeofday_clobber
> which is in Buildroot since a long time. I can't tell for every gnulib based
> packages...
>
> >
> >> +Use the same workaround [1] as gnulib use to get the original
> >> +definition of stat. Otherwise with musl toolchains, gnulib try to use
> >> +rpl_stat which is not defined.
> >
> > Well rpl_stat() is supposed to be implemented by gnulib. So basically
> > gnulib tells gdb: please don't use stat() but my rpl_stat() wrapper,
> > but then gnulib doesn't provide rpl_stat().
> >
> > Any idea what's happening here ?
>
> As far I can tell, the regression has been introduced by this commit:
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=2441702a72f324e41a1624dc042b334f375e2d81
I'm not aware of all the context, but it looks like different source
files disagree on whether gnulib has replaced stat or not -- the
gnulib source file thinks it hasn't, so the rpl_stat function isn't
defined, but gdb's common-utils-ipa.c file (or rather the gnulib
stat.h included into it?) thinks it has been replaced and is trying to
use the replacement. This is likely the result of an incorrect hack
somewhere. Do you know if it happens with upstream gdb and musl or
just in buildroot's package?
Rich
next prev parent reply other threads:[~2018-09-10 22:41 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180909163750.14196-1-romain.naour@gmail.com>
[not found] ` <20180909163750.14196-2-romain.naour@gmail.com>
[not found] ` <20180910174900.0b9f4133@windsurf>
2018-09-10 21:21 ` Romain Naour
2018-09-10 22:41 ` Rich Felker [this message]
2018-09-11 0:38 ` Sergio Durigan Junior
2018-09-11 9:51 ` Pedro Alves
2018-09-11 14:13 ` Rich Felker
2018-09-11 16:04 ` Pedro Alves
2018-09-11 18:22 ` Sergio Durigan Junior
2018-09-12 15:26 ` Pedro Alves
2018-09-12 17:11 ` Sergio Durigan Junior
2018-09-12 17:40 ` Pedro Alves
2018-09-11 10:13 ` Pedro Alves
2018-09-11 6:47 ` Thomas Petazzoni
2018-09-12 17:31 ` [PATCH] Move 'is_regular_file' from common-utils.c to filestuff.c Sergio Durigan Junior
2018-09-12 17:41 ` Pedro Alves
2018-09-12 17:59 ` Sergio Durigan Junior
2018-09-14 21:27 ` Romain Naour
2018-09-14 21:41 ` Tom Tromey
2018-09-14 21:48 ` Sergio Durigan Junior
2018-09-14 21:55 ` Romain Naour
2018-09-14 22:09 ` Joel Brobecker
2018-09-15 13:16 ` Romain Naour
2018-09-15 13:28 ` Romain Naour
2018-09-15 20:42 ` Sergio Durigan Junior
2018-09-17 17:01 ` Joel Brobecker
2018-09-15 20:35 ` Sergio Durigan Junior
2018-09-15 21:14 ` Romain Naour
2018-09-16 4:59 ` Sergio Durigan Junior
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=20180910224128.GT1878@brightrain.aerifal.cx \
--to=dalias@aerifal.cx \
--cc=buildroot@buildroot.org \
--cc=gdb-patches@sourceware.org \
--cc=romain.naour@gmail.com \
--cc=romain.naour@smile.fr \
--cc=thomas.petazzoni@bootlin.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