From: Hans-Peter Nilsson <hp@axis.com>
To: Hans-Peter Nilsson <hp@axis.com>
Cc: <christophe.lyon@linaro.org>, <gcc-patches@gcc.gnu.org>,
<jwakely@redhat.com>, <libstdc++@gcc.gnu.org>
Subject: Re: [PATCH] libstdc++: Use GLIBCXX_CHECK_LINKER_FEATURES for cross-builds (PR111238)
Date: Thu, 31 Aug 2023 21:39:30 +0200 [thread overview]
Message-ID: <20230831193930.CB9D420421@pchp3.se.axis.com> (raw)
In-Reply-To: <20230831170519.8B84620425@pchp3.se.axis.com> (message from Hans-Peter Nilsson on Thu, 31 Aug 2023 19:05:19 +0200)
> From: Hans-Peter Nilsson <hp@axis.com>
> Date: Thu, 31 Aug 2023 19:05:19 +0200
> > Date: Thu, 31 Aug 2023 17:25:45 +0200
> > From: Christophe Lyon via Gcc-patches <gcc-patches@gcc.gnu.org>
> > However, this would hide the fact that libstdc++ somehow forces the
> > user to use -Wl,-gc-sections to avoid undefined references to chdir,
> > mkdir, chmod, pathconf, ... so maybe it's better to keep the status
> > quo and not apply this patch?
I agree with the sentiment, but maybe --gc-sections should
instead be passed by default for arm-eabi when linking, with
way to opt-out; as for cris-elf per below.
> Datapoint: no failures for cris-elf in the listed tests -
> but it instead passes --gc-sections if -O2 or -O3 is seen
> for linking; see cris/cris.h. It's been like that forever,
> modulo a patch in 2002 not passing it if "-r" is seen.
>
> Incidentally, I've been sort-of investigating a recent-ish
> commit to newlib (8/8) that added a stub for getpriority,
> which was apparently added due to testsuite breakage for
> libstdc++ and arm-eabi, but that instead broke testsuite
> results for *other* targets, as warning at link-time. Film
> at 11.
>
> > 2023-08-31 Christophe Lyon <christophe.lyon@linaro.org>
> >
> > libstdc++-v3/ChangeLog:
> >
> > PR libstdc++/111238
> > * configure: Regenerate.
> > * configure.ac: Call GLIBCXX_CHECK_LINKER_FEATURES in cross,
> > non-Canadian builds.
>
> On this actual patch, I can't say yay or nay though (but
> leaning towards yay), but I'll test for cris-elf. Would you
> mind holding off committing for a day or two?
No regressions for cris-elf with this patch. Still, on one
thought I'm also not wild about libstdc++ this way
overriding the target, and on the other hand, I'll likely to
suggest something similar (adding options) to "improve"
GCC_TRY_COMPILE_OR_LINK (more targets actually linking).
brgds, H-P
next prev parent reply other threads:[~2023-08-31 19:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-31 15:25 Christophe Lyon
2023-08-31 17:05 ` Hans-Peter Nilsson
2023-08-31 19:39 ` Hans-Peter Nilsson [this message]
2023-08-31 17:42 ` Jonathan Wakely
2023-08-31 17:53 ` Jonathan Wakely
2023-08-31 19:43 ` Jonathan Wakely
2023-09-01 8:27 ` Christophe Lyon
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=20230831193930.CB9D420421@pchp3.se.axis.com \
--to=hp@axis.com \
--cc=christophe.lyon@linaro.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=jwakely@redhat.com \
--cc=libstdc++@gcc.gnu.org \
/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).