From: Pedro Alves <palves@redhat.com>
To: Sergio Durigan Junior <sergiodj@redhat.com>,
Rich Felker <dalias@aerifal.cx>
Cc: Romain Naour <romain.naour@smile.fr>,
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: Tue, 11 Sep 2018 10:13:00 -0000 [thread overview]
Message-ID: <1b73e625-c2bf-31e1-daee-61baad348ec2@redhat.com> (raw)
In-Reply-To: <87lg88oolv.fsf@redhat.com>
On 09/11/2018 01:38 AM, Sergio Durigan Junior wrote:
> I'm thinking here that this is similar to a problem we had recently,
> which existed when cross-compiling GDB. Basically, in this scenario,
> gnulib's mechanism to detect cross-compilation was poor and lead to the
> unneeded replacement of 'getcwd' in some systems that did have a working
> 'getcwd', and that was causing problems when running the cross GDB.
> The
> bug is here:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=23558
>
> and the fix was to improve gnulib's machinery and make it a bit smarter
> when detecting cross-compilation scenarios.
Just to add a bit more color here: for some cases, gnulib needs to
be able to run things on the target in order to detect whether the
function being checked needs replacement:
./m4/getcwd-abort-bug.m4: AC_RUN_IFELSE(
./m4/getcwd.m4: [AC_RUN_IFELSE([AC_LANG_PROGRAM([[
./m4/getcwd-path-max.m4: AC_RUN_IFELSE(
If you're cross compiling, then obviously you can't run things on the
target. So all you can do, is take a guess, and if you don't know
anything about the system, the best is to take a conservative guess of
"needs fixing/replacing". The gnulib fix pointed out is simply adding a
few targets to a whitelist of systems that don't need the fix/replacement,
so that when cross compiling for those systems, gnulib doesn't take the
default conservative approach.
Seems like the stat checks in gnulib also rely on running code,
and thus this could indeed be a similar case:
./m4/fstatat.m4: [AC_RUN_IFELSE(
./m4/lstat.m4: AC_RUN_IFELSE(
./m4/stat.m4: AC_RUN_IFELSE(
Though from a quick peek, if the target triplet include "linux"
or "gnu", it should guess OK:
[case "$host_os" in
# Guess yes on Linux systems.
linux-* | linux) gl_cv_func_stat_file_slash="guessing yes" ;;
# Guess yes on glibc systems.
*-gnu* | gnu*) gl_cv_func_stat_file_slash="guessing yes" ;;
# If we don't know, assume the worst.
*) gl_cv_func_stat_file_slash="guessing no" ;;
esac
So there might well be some other reason gnulib determines that stat
must be replaced on musl. The ideal would be if no replacement were
necessary at all.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2018-09-11 10:13 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
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 [this message]
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=1b73e625-c2bf-31e1-daee-61baad348ec2@redhat.com \
--to=palves@redhat.com \
--cc=buildroot@buildroot.org \
--cc=dalias@aerifal.cx \
--cc=gdb-patches@sourceware.org \
--cc=romain.naour@gmail.com \
--cc=romain.naour@smile.fr \
--cc=sergiodj@redhat.com \
--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