Strange libstdc++ versions in travis-ci testers

Andrzej Krzemienski

28 Jun 2018 28 Jun '18

7:14 p.m.

Hi Everyone, Maybe someone could help me understand the configuration on the travis-ci testers. Whenever I push a new commit I get a number of failures from travis-ci about missing std::is_trivially_default_constructible from the standard library; like here: https://travis-ci.org/boostorg/optional/builds/397519342?utm_source=email&utm_medium=notification Some tests with Boost.Predef indicate that they are clang compiler 3.X, and clang 5 with libstdc++ of strange version nubers: macro BOOST_LIB_STD_GNU gives values 450400026 and 460700026, which would correspond to releases 2015-04-26 and 2016-07-26, but when I look at the release notes for GCC there are no releases mentioned of these dates: https://gcc.gnu.org/news.html Maybe someone knows what versions of libstdc++ these are? Or maybe I am missing something obvious? Regards, &rzej;

Show replies by date

Stefan Seefeld

28 Jun 28 Jun

7:27 p.m.

On 2018-06-28 03:14 PM, Andrzej Krzemienski via Boost wrote:

...

Hi Everyone, Maybe someone could help me understand the configuration on the travis-ci testers.

For avoidance of doubt: what exactly are you referring to by "the travis-ci testers" ? Lots of Boost projects use their own CI configuration, so there is a huge variance on compilers and runtimes being used, some supporting C++11, some not.

...

Whenever I push a new commit I get a number of failures from travis-ci about missing std::is_trivially_default_constructible from the standard library; like here: https://travis-ci.org/boostorg/optional/builds/397519342?utm_source=email&utm_medium=notification

Some tests with Boost.Predef indicate that they are clang compiler 3.X, and clang 5 with libstdc++ of strange version nubers: macro BOOST_LIB_STD_GNU gives values 450400026 and 460700026, which would correspond to releases 2015-04-26 and 2016-07-26, but when I look at the release notes for GCC there are no releases mentioned of these dates: https://gcc.gnu.org/news.html

Maybe someone knows what versions of libstdc++ these are? Or maybe I am missing something obvious?

In case of doubt, you should at least add -std=c++11. It's been the default with recent g++ versions, but not with older ones. Likewise with clang. Stefan -- ...ich hab' noch einen Koffer in Berlin...

Andrzej Krzemienski

7:42 p.m.

2018-06-28 21:27 GMT+02:00 Stefan Seefeld via Boost :

...

On 2018-06-28 03:14 PM, Andrzej Krzemienski via Boost wrote:

...
Hi Everyone, Maybe someone could help me understand the configuration on the travis-ci testers.

For avoidance of doubt: what exactly are you referring to by "the travis-ci testers" ? Lots of Boost projects use their own CI configuration, so there is a huge variance on compilers and runtimes being used, some supporting C++11, some not.

This is interesting. I am referring to Boost.Opitonal tests on Travis configured here: https://travis-ci.org/boostorg/optional I am a maintainer of Boost.Optional, and I never configured these tests. They were not there a year ago, and at some point I started receiving test results from this site upon every commit. So I assume there must have been a Boost-wide initiative to put additional tests there. I assume that someone on the list might have taken part in configuring them, and may know the answers.

...

Whenever I push a new commit I get a number of failures from

...
travis-ci about missing std::is_trivially_default_constructible from the standard library; like here: https://travis-ci.org/boostorg/optional/builds/397519342? utm_source=email&utm_medium=notification

Some tests with Boost.Predef indicate that they are clang compiler 3.X, and clang 5 with libstdc++ of strange version nubers: macro BOOST_LIB_STD_GNU gives values 450400026 and 460700026, which would correspond to releases 2015-04-26 and 2016-07-26, but when I look at the release notes for GCC there are no releases mentioned of these dates: https://gcc.gnu.org/news.html

Maybe someone knows what versions of libstdc++ these are? Or maybe I am missing something obvious?

In case of doubt, you should at least add -std=c++11. It's been the default with recent g++ versions, but not with older ones. Likewise with clang.

I am not sure what you mean here. The library should be prepared for every configuration of compiler/standard-library, so I do not mind testing for C++03. My usage of std::is_trivially_default_constructible is #ifdef-ed with (__cplusplus >= 201103L). Regards, &rzej;

...

Stefan

--

...ich hab' noch einen Koffer in Berlin...

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost

Stefan Seefeld

7:56 p.m.

On 2018-06-28 03:42 PM, Andrzej Krzemienski via Boost wrote:

...

2018-06-28 21:27 GMT+02:00 Stefan Seefeld via Boost :

...
On 2018-06-28 03:14 PM, Andrzej Krzemienski via Boost wrote:

...
Hi Everyone, Maybe someone could help me understand the configuration on the travis-ci testers.

For avoidance of doubt: what exactly are you referring to by "the travis-ci testers" ? Lots of Boost projects use their own CI configuration, so there is a huge variance on compilers and runtimes being used, some supporting C++11, some not.

This is interesting. I am referring to Boost.Opitonal tests on Travis configured here: https://travis-ci.org/boostorg/optional I am a maintainer of Boost.Optional, and I never configured these tests. They were not there a year ago, and at some point I started receiving test results from this site upon every commit. So I assume there must have been a Boost-wide initiative to put additional tests there. I assume that someone on the list might have taken part in configuring them, and may know the answers.

Startling... I'm maintaining a few Boost projects, too. And I would be most concerned if someone started to add stuff into "my" repos without first discussing it with me. Stefan -- ...ich hab' noch einen Koffer in Berlin...

Andrzej Krzemienski

8:07 p.m.

2018-06-28 21:56 GMT+02:00 Stefan Seefeld via Boost :

...

On 2018-06-28 03:42 PM, Andrzej Krzemienski via Boost wrote:

2018-06-28 21:27 GMT+02:00 Stefan Seefeld via Boost
...
...
:

...
On 2018-06-28 03:14 PM, Andrzej Krzemienski via Boost wrote:

...
Maybe someone could help me understand the configuration on the travis-ci testers.

For avoidance of doubt: what exactly are you referring to by "the

Hi Everyone, travis-ci testers" ? Lots of Boost projects use their own CI configuration, so there is a huge variance on compilers and runtimes being used, some supporting C++11, some not.

This is interesting. I am referring to Boost.Opitonal tests on Travis configured here: https://travis-ci.org/boostorg/optional I am a maintainer of Boost.Optional, and I never configured these tests. They were not there a year ago, and at some point I started receiving test results from this site upon every commit. So I assume there must have been a Boost-wide initiative to put additional tests there. I assume that someone on the list might have taken part in configuring them, and may know the answers.

Startling... I'm maintaining a few Boost projects, too. And I would be most concerned if someone started to add stuff into "my" repos without first discussing it with me.

I do not see it this way. I get additional machines executing my tests for free. I can be but grateful. I just want to understand how they are configured, so that I can address these configurations in my library. Regards, &rzej;

Stefan Seefeld

8:16 p.m.

On 2018-06-28 04:07 PM, Andrzej Krzemienski via Boost wrote:

...

2018-06-28 21:56 GMT+02:00 Stefan Seefeld via Boost :

Startling... I'm maintaining a few Boost projects, too. And I would be most concerned if someone started to add stuff into "my" repos without first discussing it with me.

I do not see it this way. I get additional machines executing my tests for free. I can be but grateful. I just want to understand how they are configured, so that I can address these configurations in my library.

That's my point: I'd of course be grateful for any help, but if it generates errors I don't understand, that wouldn't really be helpful, would it. Stefan -- ...ich hab' noch einen Koffer in Berlin...

Peter Dimov

9:34 p.m.

Andrzej Krzemienski wrote:

...

This is interesting. I am referring to Boost.Opitonal tests on Travis configured here: https://travis-ci.org/boostorg/optional I am a maintainer of Boost.Optional, and I never configured these tests. They were not there a year ago, and at some point I started receiving test results from this site upon every commit.

Yeah, that's my fault. https://github.com/boostorg/optional/commit/e9f5641be37750a8976546ecfffbcb8e... The default libstdc++ on Travis matches the default g++, which is at present 4.8, if I'm not mistaken. Each g++ uses its corresponding libstdc++, so the default one is used only by Clang; but if a newer one is installed, Clang picks that up. So given the .travis.yml file from the above commit, clang 3.5, 3.8, 3.9 use libstdc++ 4.9 (because it's being installed), the rest use the default one. This is presumably because those versions failed with libstdc++ 4.8 at the time I activated Travis. To detect the actual libstdc++ version, you should use the Boost.Config macro, as it's generally more reliable.

Andrzej Krzemienski

10:10 p.m.

2018-06-28 23:34 GMT+02:00 Peter Dimov via Boost :

...

Andrzej Krzemienski wrote:

This is interesting. I am referring to Boost.Opitonal tests on Travis

...
configured here: https://travis-ci.org/boostorg/optional I am a maintainer of Boost.Optional, and I never configured these tests. They were not there a year ago, and at some point I started receiving test results from this site upon every commit.

Yeah, that's my fault.

https://github.com/boostorg/optional/commit/e9f5641be37750a8 976546ecfffbcb8ee08f8648

The default libstdc++ on Travis matches the default g++, which is at present 4.8, if I'm not mistaken. Each g++ uses its corresponding libstdc++, so the default one is used only by Clang; but if a newer one is installed, Clang picks that up. So given the .travis.yml file from the above commit, clang 3.5, 3.8, 3.9 use libstdc++ 4.9 (because it's being installed), the rest use the default one. This is presumably because those versions failed with libstdc++ 4.8 at the time I activated Travis.

Thanks for the info.

...

To detect the actual libstdc++ version, you should use the Boost.Config macro, as it's generally more reliable.

Do you mean macro BOOST_STDLIB ? In what way is it more reliable? It gives me a string like "GNU libstdc++ version 20180125" and it would be difficult to use #ifdef-s on it. BTW, is there a known way to tell the library series 4.9 from from series 5.0? The date alone does not seem to be good enough. Regards, &rzej;

Peter Dimov

11:06 p.m.

Andrzej Krzemienski wrote:

...

...
To detect the actual libstdc++ version, you should use the Boost.Config macro, as it's generally more reliable.

Do you mean macro BOOST_STDLIB ?

I meant BOOST_LIBSTDCXX_VERSION, sorry.

Rene Rivera

29 Jun 29 Jun

1:51 a.m.

On Thu, Jun 28, 2018 at 4:40 PM Peter Dimov via Boost wrote:

...

To detect the actual libstdc++ version, you should use the Boost.Config macro, as it's generally more reliable.

Why is it more reliable? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

Peter Dimov

2:10 a.m.

Rene Rivera wrote:

...

On Thu, Jun 28, 2018 at 4:40 PM Peter Dimov via Boost wrote:

...
To detect the actual libstdc++ version, you should use the Boost.Config macro, as it's generally more reliable.

Why is it more reliable?

__GLIBCXX__ is a date, which is not very useful for determining the version. There's _GLIBCXX_RELEASE but that's only for 7 and up. Config uses __has_include to detect the version under Clang, __GNUC__ under g++.

Rene Rivera

2:55 a.m.

On Thu, Jun 28, 2018 at 9:11 PM Peter Dimov via Boost wrote:

...

Rene Rivera wrote:

...
On Thu, Jun 28, 2018 at 4:40 PM Peter Dimov via Boost wrote:

...
To detect the actual libstdc++ version, you should use the Boost.Config macro, as it's generally more reliable.

Why is it more reliable?

__GLIBCXX__ is a date, which is not very useful for determining the version.

Which is what Predef uses. And also uses __GLIBCPP__ as fallback. But, yes they are dates, as that's the only real indicator of *only* libstdc++ I knew of. There's _GLIBCXX_RELEASE but that's only for 7 and up. Config uses

...

Hm, hadn't kept up on that. I'll have to add that if available.

...

__has_include to detect the version under Clang,

How would __has_include help?

...

__GNUC__ under g++.

But that's the g++ version, not the lib version. I guess I should check the Config code :-) -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

Jonathan Wakely

15 Aug 15 Aug

10:31 p.m.

On Fri, 29 Jun 2018 at 03:56, Rene Rivera via Boost wrote:

...

On Thu, Jun 28, 2018 at 9:11 PM Peter Dimov via Boost wrote:

...
Rene Rivera wrote:

...
On Thu, Jun 28, 2018 at 4:40 PM Peter Dimov via Boost wrote:

...
To detect the actual libstdc++ version, you should use the Boost.Config macro, as it's generally more reliable.

Why is it more reliable?

__GLIBCXX__ is a date, which is not very useful for determining the version.

Which is what Predef uses. And also uses __GLIBCPP__ as fallback. But, yes they are dates, as that's the only real indicator of *only* libstdc++ I knew of.

There's _GLIBCXX_RELEASE but that's only for 7 and up. Config uses

...
Hm, hadn't kept up on that. I'll have to add that if available.

See https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_macros.html which also has a link to https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html#abi.versioning.__GL... explaining why the __GLIBCXX__ and __GLIBCPP__ macros are useless for determining the version.

...

...
__has_include to detect the version under Clang,

How would __has_include help?

By checking for the presence of a header that was added in a particular version. If is available, you're using at least GCC 4.9

...

...
__GNUC__ under g++.

But that's the g++ version, not the lib version.

When you're using g++ the lib version *is* the g++ version. Using older or newer versions of libstdc++ with g++ is not supported, you have to use the bundled one. So when compiling with g++ the compiler version and the library version are the same.

2295

Age (days ago)

2343

Last active (days ago)

List overview

Download

12 comments

5 participants

participants (5)

Andrzej Krzemienski
Jonathan Wakely
Peter Dimov
Rene Rivera
Stefan Seefeld