public inbox for libstdc++@gcc.gnu.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Ed Smith-Rowland <3dw4rd@verizon.net>,
	Jonathan Wakely <jwakely@redhat.com>
Cc: "libstdc++@gcc.gnu.org" <libstdc++@gcc.gnu.org>,
	gcc-patches <gcc-patches@gcc.gnu.org>,
	Jonathan Wakely <jwakely.gcc@gmail.com>,
	redi@gcc.gnu.org
Subject: Re: [PATCH libstdc++/66689] comp_ellint_3 and ellint_3 return garbage values
Date: Tue, 21 Nov 2017 11:33:00 -0000	[thread overview]
Message-ID: <8c63977a-6d6c-44b9-876b-5d01bd38e95b@redhat.com> (raw)
In-Reply-To: <fde24434-0c04-c369-8956-f9c4b0024bfb@verizon.net>

On 11/18/2017 05:49 PM, Ed Smith-Rowland wrote:
> I feel that distros are likely to pick up gcc-7 soon and I'd like to do 
> *something*.  This would be something of a transition path.

Historically, in glibc, we would have used symbol versioning for this, 
so that existing binaries retain the old behavior.  The downside is that 
blind recompilation will give you the change in behavior, so it 
essentially benefits proprietary software vendors only, which is why I 
think it's usually not appropriate to do this because either you want 
the fix for all applications, recompiled or not, or you don't.

In addition, in Fedora and downstream, we cannot backport new symbol 
versions unless the symbol version is unique to the feature/bug fix 
being added, due to the way RPM dependencies are generated.

Thanks,
Florian

  parent reply	other threads:[~2017-11-21 11:33 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-17 20:06 Ed Smith-Rowland
2017-11-17 20:54 ` Jonathan Wakely
2017-11-18 16:49   ` Ed Smith-Rowland
2017-11-20 16:39     ` Jonathan Wakely
2017-11-21 11:33     ` Florian Weimer [this message]
2017-11-21 13:35       ` Jonathan Wakely
2017-11-22  0:19       ` Joseph Myers
2017-11-20 16:02 David Edelsohn
2017-11-20 20:44 ` Christophe Lyon
2017-11-20 21:01   ` Jonathan Wakely
2017-11-20 21:07     ` Jonathan Wakely
2017-11-20 21:51       ` Jonathan Wakely
2017-12-05 18:36         ` David Edelsohn

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=8c63977a-6d6c-44b9-876b-5d01bd38e95b@redhat.com \
    --to=fweimer@redhat.com \
    --cc=3dw4rd@verizon.net \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jwakely.gcc@gmail.com \
    --cc=jwakely@redhat.com \
    --cc=libstdc++@gcc.gnu.org \
    --cc=redi@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).