From: Jonathan Wakely <jwakely@redhat.com>
To: "François Dumont" <frs.dumont@gmail.com>
Cc: "libstdc++@gcc.gnu.org" <libstdc++@gcc.gnu.org>,
gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Fix version namespace build
Date: Thu, 11 Feb 2021 17:29:22 +0000 [thread overview]
Message-ID: <20210211172922.GE3008@redhat.com> (raw)
In-Reply-To: <YCVL4a6TKgtQMZrB@redhat.com>
On 11/02/21 15:23 +0000, Jonathan Wakely wrote:
>On 09/02/21 22:05 +0100, François Dumont via Libstdc++ wrote:
>> libstdc++: Fix versioned namespace build
>>
>> libstdc++-v3/ChangeLog:
>>
>> * libsupc++/eh_ptr.cc (exception_ptr(__safe_bool)): Define if
>> _GLIBCXX_EH_PTR_COMPAT is defined.
>> (exception_ptr::_M_safe_bool_dummy()): Likewise.
>> (exception_ptr::operator!()): Likewise.
>> (exception_ptr::opeerator __safe_bool()): Likewise.
>>
>>Ok to commit ?
>
>No, this is not correct. Those functions are declared in the
>header if included from C++98 code:
>
>#if (__cplusplus < 201103L) || defined (_GLIBCXX_EH_PTR_COMPAT)
> typedef void (exception_ptr::*__safe_bool)();
>
> // For construction from nullptr or 0.
> exception_ptr(__safe_bool) _GLIBCXX_USE_NOEXCEPT;
>#endif
>
>With your change, C++98 code that calls those functions will be unable
>to link to libstdc++.so.8 because the functions won't be defined in
>the library.
>
>The simplest fix would be to revert this change:
>
>--- a/libstdc++-v3/libsupc++/eh_ptr.cc
>+++ b/libstdc++-v3/libsupc++/eh_ptr.cc
>@@ -25,7 +25,12 @@
> #include <bits/c++config.h>
> #include "eh_atomics.h"
>
>+#if ! _GLIBCXX_INLINE_VERSION
>+// This macro causes exception_ptr to declare an older API (with corresponding
>+// definitions in this file) and to mark some inline functions as "used" so
>+// that definitions will be emitted in this translation unit.
> #define _GLIBCXX_EH_PTR_COMPAT
>+#endif
>
> #include <exception>
> #include <bits/exception_ptr.h>
>
>But that leaves the unwanted operator== definitions in libstdc++.so.8
>so the attached patch (only tested with unversioned namespace) is
>probably what we want to do. Does it fix the problem?
I've now tested the patch below and committed it.
>diff --git a/libstdc++-v3/libsupc++/eh_ptr.cc b/libstdc++-v3/libsupc++/eh_ptr.cc
>index 5d8ac1d879a..5c4685606fe 100644
>--- a/libstdc++-v3/libsupc++/eh_ptr.cc
>+++ b/libstdc++-v3/libsupc++/eh_ptr.cc
>@@ -25,11 +25,15 @@
> #include <bits/c++config.h>
> #include "eh_atomics.h"
>
>-#if ! _GLIBCXX_INLINE_VERSION
> // This macro causes exception_ptr to declare an older API (with corresponding
>-// definitions in this file) and to mark some inline functions as "used" so
>-// that definitions will be emitted in this translation unit.
>+// definitions in this file).
> #define _GLIBCXX_EH_PTR_COMPAT
>+
>+#if ! _GLIBCXX_INLINE_VERSION
>+// This macro causes some inline functions in exception_ptr to be marked
>+// as "used" so that definitions will be emitted in this translation unit.
>+// We need this because those functions were not inline in previous releases.
>+#define _GLIBCXX_EH_PTR_RELOPS_COMPAT
> #endif
>
> #include <exception>
>diff --git a/libstdc++-v3/libsupc++/exception_ptr.h b/libstdc++-v3/libsupc++/exception_ptr.h
>index 6d41b34fabe..9943668d9b3 100644
>--- a/libstdc++-v3/libsupc++/exception_ptr.h
>+++ b/libstdc++-v3/libsupc++/exception_ptr.h
>@@ -39,7 +39,7 @@
> #include <typeinfo>
> #include <new>
>
>-#ifdef _GLIBCXX_EH_PTR_COMPAT
>+#ifdef _GLIBCXX_EH_PTR_RELOPS_COMPAT
> # define _GLIBCXX_EH_PTR_USED __attribute__((__used__))
> #else
> # define _GLIBCXX_EH_PTR_USED
>@@ -153,7 +153,7 @@ namespace std
> #endif
>
> #if __cpp_impl_three_way_comparison >= 201907L \
>- && ! defined _GLIBCXX_EH_PTR_COMPAT
>+ && ! defined _GLIBCXX_EH_PTR_RELOPS_COMPAT
> friend bool
> operator==(const exception_ptr&, const exception_ptr&) noexcept = default;
> #else
prev parent reply other threads:[~2021-02-11 17:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-09 21:05 François Dumont
2021-02-11 15:23 ` Jonathan Wakely
2021-02-11 17:29 ` Jonathan Wakely [this message]
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=20210211172922.GE3008@redhat.com \
--to=jwakely@redhat.com \
--cc=frs.dumont@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--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).