Using SCLs to build a C++ library for EL 7?

[Dan Čermák]

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

[Neal Gompa]

On Mon, Apr 29, 2019 at 7:50 AM Dan Čermák
<dan.cermak(a)cgc-instruments.com&gt; 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.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Jonathan Wakely]

On 29/04/19 07:52 -0400, Neal Gompa wrote:
> On Mon, Apr 29, 2019 at 7:50 AM Dan Čermák
> <dan.cermak(a)cgc-instruments.com&gt; 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.

[John Reiser]

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(a)cgc-instruments.com&gt; 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.

[Dan Čermák]

John Reiser <jreiser(a)bitwagon.com&gt; 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(a)cgc-instruments.com&gt; 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Georg Sauthoff]

On Mon, Apr 29, 2019 at 05:11:53PM +0200, Dan Čermák wrote:
>  John Reiser <jreiser(a)bitwagon.com&gt; 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
-- 
'Embrace change' (Barack Ob^W^WKent Beck)

[Jonathan Wakely]

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(a)bitwagon.com&gt; 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-...

> 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.

[Georg Sauthoff]

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(a)bitwagon.com&gt; 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-...
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

-- 
"No one can write decently who is distrustful of the reader's
intelligence, or whose attitude is patronizing." (William Strunk,
Jr. and E.B. White, The Elements of Style, p. 70, 1959)

[Jonathan Wakely]

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(a)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...

The C++0x support in GCC 4.8 was experimental and unstable, so the
caveats explained at https://stackoverflow.com/a/49119902/981959
apply.

[Stephen John Smoogen]

On Mon, 29 Apr 2019 at 07:51, Dan Čermák <dan.cermak(a)cgc-instruments.com&gt;
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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  

-- 
Stephen J Smoogen.