From: Joseph Myers <joseph@codesourcery.com>
To: Torvald Riegel <triegel@redhat.com>
Cc: Mike Crowe <mac@mcrowe.com>, Jonathan Wakely <jwakely@redhat.com>,
<libstdc++@gcc.gnu.org>, <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH 2/5] libstdc++ futex: Use FUTEX_CLOCK_REALTIME for wait
Date: Fri, 12 Jan 2018 17:56:00 -0000 [thread overview]
Message-ID: <alpine.DEB.2.20.1801121750450.10212@digraph.polyomino.org.uk> (raw)
In-Reply-To: <1515763080.4439.129.camel@redhat.com>
On Fri, 12 Jan 2018, Torvald Riegel wrote:
> Another option might be to require a minimum glibc version on Linux, and
> build libstdc++ for that. That would yield a minimum kernel version as
> well, and we may can make use of other things in return such as syscall
> wrappers.
A minimum glibc version of course only applies when libstdc++ is being
built with glibc - it can also be built with other C libraries using the
Linux kernel (and some - at least uClibc - define __GLIBC__ to pretend to
be some old glibc version).
One thing to note regarding minimum glibc (or kernel) versions is it can
be useful to use new GCC to build binaries to run on older systems - which
means building new GCC as a cross compiler with a sysroot with an old
glibc version in it. So the relevant question for establishing a minimum
glibc or kernel version is not what systems people are using to develop
GCC, but what systems they might want to deploy binaries built with
current GCC onto.
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2018-01-12 17:56 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-07 20:55 [PATCH 0/5] Make std::future::wait_* use std::chrono::steady_clock when required Mike Crowe
2018-01-07 20:55 ` [PATCH 1/5] Improve libstdc++-v3 async test Mike Crowe
2018-01-09 14:31 ` Jonathan Wakely
2018-01-07 20:55 ` [PATCH 3/5] libstdc++ futex: Support waiting on std::chrono::steady_clock directly Mike Crowe
2018-01-07 20:55 ` [PATCH 5/5] Extra async tests, not for merging Mike Crowe
2018-01-07 20:55 ` [PATCH 2/5] libstdc++ futex: Use FUTEX_CLOCK_REALTIME for wait Mike Crowe
2018-01-09 13:50 ` Jonathan Wakely
2018-01-09 17:54 ` Mike Crowe
2018-01-12 13:18 ` Torvald Riegel
2018-01-12 14:49 ` Jonathan Wakely
2018-01-12 17:56 ` Joseph Myers [this message]
2018-01-07 20:55 ` [PATCH 4/5] libstdc++ atomic_futex: Use std::chrono::steady_clock as reference clock Mike Crowe
2018-01-09 14:43 ` [PATCH 0/5] Make std::future::wait_* use std::chrono::steady_clock when required Jonathan Wakely
2018-01-13 15:30 ` Torvald Riegel
2018-01-14 16:08 ` Mike Crowe
2018-01-14 20:44 ` Mike Crowe
2018-02-14 16:32 ` Mike Crowe
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=alpine.DEB.2.20.1801121750450.10212@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jwakely@redhat.com \
--cc=libstdc++@gcc.gnu.org \
--cc=mac@mcrowe.com \
--cc=triegel@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).