Hi list,
I'm co-maintaining a C++ library that has been continuously updated in CentOS 7 but a recent change made it incompatible with the default GCC version available in el7. I.e. the next release (scheduled for the end of 2019) will FTBFS in CentOS/RHEL 7.
Would it be fine to require a gcc version from a SCL to build this library? I'm afraid that due to the nature of C++'s non-standardized ABI it would require all dependent packages to be rebuild with gcc from the SCL too.
Cheers,
Dan
On Mon, Apr 29, 2019 at 7:50 AM Dan Čermák dan.cermak@cgc-instruments.com wrote:
Hi list,
I'm co-maintaining a C++ library that has been continuously updated in CentOS 7 but a recent change made it incompatible with the default GCC version available in el7. I.e. the next release (scheduled for the end of 2019) will FTBFS in CentOS/RHEL 7.
Would it be fine to require a gcc version from a SCL to build this library? I'm afraid that due to the nature of C++'s non-standardized ABI it would require all dependent packages to be rebuild with gcc from the SCL too.
Software Collections GCC is configured to follow C++ ABI from system GCC. This puts some limitations on the libstdc++ shipped by SCL GCC, but allows us to avoid that problem entirely.
On 29/04/19 07:52 -0400, Neal Gompa wrote:
On Mon, Apr 29, 2019 at 7:50 AM Dan Čermák dan.cermak@cgc-instruments.com wrote:
Hi list,
I'm co-maintaining a C++ library that has been continuously updated in CentOS 7 but a recent change made it incompatible with the default GCC version available in el7. I.e. the next release (scheduled for the end of 2019) will FTBFS in CentOS/RHEL 7.
Would it be fine to require a gcc version from a SCL to build this library? I'm afraid that due to the nature of C++'s non-standardized ABI it would require all dependent packages to be rebuild with gcc from the SCL too.
Software Collections GCC is configured to follow C++ ABI from system GCC. This puts some limitations on the libstdc++ shipped by SCL GCC, but allows us to avoid that problem entirely.
If you're talking about the devtoolset version of GCC, that's not strictly true. There are limitations on what is supported, so the problem isn't avoided entirely.
It would be useful for posts to be specific, and/or to include a link to a detailed explanation. Such information might attract the interest of others, and tend to encourage the discovery of multiple approaches towards dealing with the underlying problems.
On 4/29/19 1210 UTC, Jonathan Wakely wrote:
On 29/04/19 07:52 -0400, Neal Gompa wrote:
On Mon, Apr 29, 2019 at 7:50 AM Dan Čermák dan.cermak@cgc-instruments.com wrote:
Hi list,
I'm co-maintaining a C++ library that has been continuously updated in
Which library in which package?
CentOS 7 but a recent change made it incompatible with the default GCC version available in el7. I.e. the next release (scheduled for the end of 2019) will FTBFS in CentOS/RHEL 7.
What is the nature of the incompatibilities, and what are specific examples?
Would it be fine to require a gcc version from a SCL to build this library? I'm afraid that due to the nature of C++'s non-standardized ABI it would require all dependent packages to be rebuild with gcc from the SCL too.
Software Collections GCC is configured to follow C++ ABI from system GCC. This puts some limitations on the libstdc++ shipped by SCL GCC,
For example, or a link to an explanation?
but allows us to avoid that problem entirely.
If you're talking about the devtoolset version of GCC, that's not strictly true. There are limitations on what is supported, so the
For example; or a link to an explanation?
problem isn't avoided entirely.
John Reiser jreiser@bitwagon.com writes:
It would be useful for posts to be specific, and/or to include a link to a detailed explanation. Such information might attract the interest of others, and tend to encourage the discovery of multiple approaches towards dealing with the underlying problems.
On 4/29/19 1210 UTC, Jonathan Wakely wrote:
On 29/04/19 07:52 -0400, Neal Gompa wrote:
On Mon, Apr 29, 2019 at 7:50 AM Dan Čermák dan.cermak@cgc-instruments.com wrote:
Hi list,
I'm co-maintaining a C++ library that has been continuously updated in
Which library in which package?
libexiv2 in the exiv2 package.
CentOS 7 but a recent change made it incompatible with the default GCC version available in el7. I.e. the next release (scheduled for the end of 2019) will FTBFS in CentOS/RHEL 7.
What is the nature of the incompatibilities, and what are specific examples?
We switched to from the POSIX regex library to <regex> as it should be provided by a C++11 compatible compiler. Unfortunately gcc 4.8.5 does not properly implement <regex> and it made a lot of tests fail. We have therefore switched to using the SCL gcc & clang compiler for now.
Would it be fine to require a gcc version from a SCL to build this library? I'm afraid that due to the nature of C++'s non-standardized ABI it would require all dependent packages to be rebuild with gcc from the SCL too.
Software Collections GCC is configured to follow C++ ABI from system GCC. This puts some limitations on the libstdc++ shipped by SCL GCC,
For example, or a link to an explanation?
but allows us to avoid that problem entirely.
If you're talking about the devtoolset version of GCC, that's not strictly true. There are limitations on what is supported, so the
For example; or a link to an explanation?
problem isn't avoided entirely.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Mon, Apr 29, 2019 at 05:11:53PM +0200, Dan Čermák wrote:
John Reiser jreiser@bitwagon.com writes:
[..]
What is the nature of the incompatibilities, and what are specific examples?
We switched to from the POSIX regex library to <regex> as it should be provided by a C++11 compatible compiler. Unfortunately gcc 4.8.5 does not properly implement <regex> and it made a lot of tests fail. We have therefore switched to using the SCL gcc & clang compiler for now.
Yes, at least GCC 4.8/4.9 (with the then current libstdc++) featured a severely broken <regex> (e.g. also on Fedora 19).
If it's just <regex> an alternative is to fallback to Boost regex - e.g. like this:
#ifdef SOME_MACRO_THAT_SIGNALS_PROPER_REGEX_AVAILABILITY #include <regex> namespace re = std; #else #include <boost/regex.hpp> namespace re = boost; #endif
And then use re::regex re::regex_match etc. in your code.
Best regards Georg
On 29/04/19 18:16 +0200, Georg Sauthoff wrote:
On Mon, Apr 29, 2019 at 05:11:53PM +0200, Dan Čermák wrote:
John Reiser jreiser@bitwagon.com writes:
[..]
What is the nature of the incompatibilities, and what are specific examples?
We switched to from the POSIX regex library to <regex> as it should be provided by a C++11 compatible compiler. Unfortunately gcc 4.8.5 does not properly implement <regex> and it made a lot of tests fail. We have therefore switched to using the SCL gcc & clang compiler for now.
Yes, at least GCC 4.8/4.9 (with the then current libstdc++) featured a severely broken <regex> (e.g. also on Fedora 19).
GCC 4.8 does, but the std::regex in 4.9 is OK. https://stackoverflow.com/questions/12530406/is-gcc-4-8-or-earlier-buggy-abo...
If it's just <regex> an alternative is to fallback to Boost regex
- e.g. like this:
#ifdef SOME_MACRO_THAT_SIGNALS_PROPER_REGEX_AVAILABILITY
https://stackoverflow.com/a/41186162/981959 shows a working version of that macro.
#include <regex> namespace re = std; #else #include <boost/regex.hpp> namespace re = boost; #endif
And then use re::regex re::regex_match etc. in your code.
Yes, this is a reasonable workaround.
On Tue, Apr 30, 2019 at 08:58:08AM +0100, Jonathan Wakely wrote:
On 29/04/19 18:16 +0200, Georg Sauthoff wrote:
On Mon, Apr 29, 2019 at 05:11:53PM +0200, Dan Čermák wrote:
John Reiser jreiser@bitwagon.com writes:
[..]
What is the nature of the incompatibilities, and what are specific examples?
We switched to from the POSIX regex library to <regex> as it should be provided by a C++11 compatible compiler. Unfortunately gcc 4.8.5 does not properly implement <regex> and it made a lot of tests fail. We have therefore switched to using the SCL gcc & clang compiler for now.
Yes, at least GCC 4.8/4.9 (with the then current libstdc++) featured a severely broken <regex> (e.g. also on Fedora 19).
GCC 4.8 does, but the std::regex in 4.9 is OK. https://stackoverflow.com/questions/12530406/is-gcc-4-8-or-earlier-buggy-abo...
There were also some std::regex issues in 4.9, e.g.:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64302 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64303 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63497
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582 (still open)
Best regards Georg
On 29/04/19 07:49 -0700, John Reiser wrote:
It would be useful for posts to be specific, and/or to include a link to a detailed explanation. Such information might attract the interest of others, and tend to encourage the discovery of multiple approaches towards dealing with the underlying problems.
On 4/29/19 1210 UTC, Jonathan Wakely wrote:
On 29/04/19 07:52 -0400, Neal Gompa wrote:
On Mon, Apr 29, 2019 at 7:50 AM Dan Čermák dan.cermak@cgc-instruments.com wrote:
Hi list,
I'm co-maintaining a C++ library that has been continuously updated in
Which library in which package?
CentOS 7 but a recent change made it incompatible with the default GCC version available in el7. I.e. the next release (scheduled for the end of 2019) will FTBFS in CentOS/RHEL 7.
What is the nature of the incompatibilities, and what are specific examples?
Would it be fine to require a gcc version from a SCL to build this library? I'm afraid that due to the nature of C++'s non-standardized ABI it would require all dependent packages to be rebuild with gcc from the SCL too.
Software Collections GCC is configured to follow C++ ABI from system GCC. This puts some limitations on the libstdc++ shipped by SCL GCC,
For example, or a link to an explanation?
The cxx11 ABI that provides new versions of std::string and std::list is not available in the devtoolset GCC for rhel7/centos7, because it can't be supported by the rhel7 system libstdc++.so
So defining _GLIBCXX_USE_CXX11_ABI=1 does nothing, you always get the old ABI.
but allows us to avoid that problem entirely.
If you're talking about the devtoolset version of GCC, that's not strictly true. There are limitations on what is supported, so the
For example; or a link to an explanation?
The devtoolset user guide: https://access.redhat.com/documentation/en-us/red_hat_developer_toolset/8/ht...
The C++0x support in GCC 4.8 was experimental and unstable, so the caveats explained at https://stackoverflow.com/a/49119902/981959 apply.
On Mon, 29 Apr 2019 at 07:51, Dan Čermák dan.cermak@cgc-instruments.com wrote:
Hi list,
I'm co-maintaining a C++ library that has been continuously updated in CentOS 7 but a recent change made it incompatible with the default GCC version available in el7. I.e. the next release (scheduled for the end of 2019) will FTBFS in CentOS/RHEL 7.
I think this question should be more aimed at the epel-devel list versus the fedora devel list.. EPEL does allow for SCL's to be used for building packages but not for requiring it to be installed.
Would it be fine to require a gcc version from a SCL to build this library? I'm afraid that due to the nature of C++'s non-standardized ABI it would require all dependent packages to be rebuild with gcc from the SCL too.
Will bow to what Neal and others say on this part.
Cheers,
Dan _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
-
Dan Čermák -
Georg Sauthoff -
John Reiser -
Jonathan Wakely -
Neal Gompa -
Stephen John Smoogen