From: Romain Naour <romain.naour@smile.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 2/2] package/gdb: use stat() privided by the system
Date: Mon, 10 Sep 2018 23:20:58 +0200 [thread overview]
Message-ID: <d588888e-dccc-50c8-5a6e-9c5c46a512cb@smile.fr> (raw)
In-Reply-To: <20180910174900.0b9f4133@windsurf>
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
Best regards,
Romain
>
> Thomas
>
next prev parent reply other threads:[~2018-09-10 21:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-09 16:37 [Buildroot] [PATCH 1/2] package/gdb: move patch directory Romain Naour
2018-09-09 16:37 ` [Buildroot] [PATCH 2/2] package/gdb: use stat() privided by the system Romain Naour
2018-09-10 15:49 ` Thomas Petazzoni
2018-09-10 21:20 ` Romain Naour [this message]
[not found] ` <20180910224128.GT1878@brightrain.aerifal.cx>
2018-09-11 6:46 ` Thomas Petazzoni
2018-09-12 21:46 ` Thomas Petazzoni
2018-09-10 15:22 ` [Buildroot] [PATCH 1/2] package/gdb: move patch directory Thomas Petazzoni
2018-10-01 14:59 ` Peter Korsgaard
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=d588888e-dccc-50c8-5a6e-9c5c46a512cb@smile.fr \
--to=romain.naour@smile.fr \
--cc=buildroot@busybox.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.