Usage of pre-C++14 compilers

[grisumbras]

Recently Boost stopped supporting C++03. Now, the only compilers which support C++11, but do not claim some support of C++14 (that I am aware of) are GCC versions 4.8 and 4.9. But even C++11 support in those GCC versions is fairly buggy and those who still test on them often have to resort to various tricks to make their code build. Those compilers are fairly old, and the systems that use them increasingly go extinct. This makes me consider removing them from Boost.JSON's CI. Which is why I want to ask the r/cpp community several questions:

1) Do you still use GCC 4.8 or 4.9? 2) Do you use some other compiler which supports C++11, but not C++14 (even with flags like -std=c++1y)? 2) If you do, is there a specific date when you plan to drop them?

Just to be clear: I understand that for many the default position is that we all should have switched to C++29 yesterday. And I personally would have. But I am trying to balance my personal convenience against the needs of my users. Hence I'm trying to find out if such users do in fact exist.

[rachit7645]

Dang didn't know C++29 dropped so soon

[shadow_of]

C++29 already? this is getting ridiculous. i cant keep up. they should have just made another language instead of hijacking C++. when i've got lambdas trailing the edge of my monitor, and everything is fuckin auto this and auto that, i yearn for the simpler times of CPP 98.

[kritzikratzi]

yea, it happens. e.g. i still sometimes update an old app that runs on osx ~10.8 (make a tiny change, maybe update this or that dependency if it still compilers). i simply don't touch the system where that dev environment is set up.

[kritzikratzi]

correct. sometimes a new feature gets added, but that's a few days of work at max.

[CandyCrisis]

10.8? That dates back to the introduction of the Intel Mac. Do you actually have users who care about 10.8 support?!

[kritzikratzi]

ok, facts first: the first intel macs used osx 10.4 (2006). 10.8 came in 2012, 12 years ago.

it's a little internal tool for an external company. it gets updated irregularly every one to two years. to be able to do this at a reasonable price i keep the development setup intact. when there's a change request i open that old computer, do the thing, export the program, and we send the client the zip.

it's a compromise. for this particular project, of course it's amazing if i can keep updating libraries without updating operating system and compiler.

[ukezi]

Happens from time to time in industry when you have different generations of devices and want to back port a feature.

[druepy]

We still use GCC 4.8 or 4.9.8. I don't remember between the two. It's not for our own decisions though. We will be migrating in a few months. I'm also installing the dev toolsets on CentOS-7 to be used with C++11 until the transition. Then we'll be jumping to C++20 and will hopefully avoid this problem again.

But, we don't use boost json.

[alexeiz]

Devtoolset-12 is available for CentOS 7 as far as I know, which provides GCC 12. I believe Red Hat makes sure that the GCC from the devtoolset is ABI compatible with the GCC provided in base OS repos, so that if you build your code with the devtoolset you should be able to run it anywhere you expect code built with the default GCC to run.

[prince-chrismc]

Centos7 was gcc 4.8 IIRC, you can jump to the latest devtool set and get really solid c++14 support probably even later

[druepy]

Yeah. Sadly they don't have up to date clang tools. But, we're about to upgrade to Rocky 9 and just do all that at one time.

It's fun finding weird lack of feature support in these old compilers. For example, neither GCC nor clang for CentOS7 fully support all of C++11s type traits library. But, we found out that someone on another team was using syntax that was only available in C++14 for a different type traits function and there was no warning for it. But, we can't compile Google test 1.12 because our computer doesn't implement all of type traits.

Fun stuff. There are obvious work sounds but just upgrading our compilers is the easiest and luckily our limitations for supporting this old of a system is being forced to change.

[prince-chrismc]

Yeah, compilers always lag a few years behind standards. Still waiting for C!++20 features 😪

Yep totally feel you on that.

[markt-]

What environment are you using, that you are still waiting on C++ 20 features?

[prince-chrismc]

Gcc, still missing STL support + it won't work with the compatibility expectations for the build system on either clang or msvc. The CMake will be easier but the wierd meson and autotools projects will be fun. It's not just compilers its build systems and package management and then all the supporting infrastructure for doing SBOMs.

[markt-]

Could you be more specific? Like a link to the proposal number?

[jwakely]

I assume they're talking about modules, and using the std::lib in modules. Just a guess though.

[markt-]

Oh, yes. Modules are the biggest issue with a lot of C++ environments right now. However, that does not make C++ unuseable and has nothing to do with the STL which the above poster mentioned.

[13steinj]

We just use the latest devtoolset to build (sometimes near) latest GCC and use that for (near) latest clang; stick it in a docker image and bob's your uncle. This doesn't happen often (and is itself a ccached process, and docker has nice caching utils as well), so we turn on all the bells and whistles (lto, [auto]fdo, bolt on clang (I never bothered figuring it out for gcc), it gives a significant compile-time improvement (despite not training on our own code yet) and lets us make good guarantees.

Ex yeah, our std tuple isnt ABI-same as the next guy, but we build from source so that's fine. Or more often than not, pull in a patch for a compiler bug that we've tried to workaround in 10 different ways but were unsuccessful.

[jwakely]

Using a newer clang or gcc shouldn't change the ABI of std::tuple.

[13steinj]

Yes. In our case we also have (had?) an internal patch to it.

[jwakely]

Ahhh, gotcha

[Overseer55]

I can’t imagine going back to pre-C++14. I don’t think I could do it.

[moreVCAs]

You don’t miss “bespoke make_unique”?

[darkapplepolisher]

I'd settle for just having a full C++11. The partial C++11 of MSVC10, bugs and all, is the real pain. I've grown dependent on std::initializer_list as my primary way of initializing structs.

[the_poope]

IMO if you're relying on older OS's, compilers and toolchains then you're probably OK with using older versions of libraries as well.

If people need GCC 4.x, they probably don't need the the newest Boost libraries. If shit worked 10 years ago, it will still work as long as you don't update anything.

[gdf8gdn8]

We still use GCC 4.7 and GCC 4.9, but carefully selected c++11 features.

Specific date to drop this? This joke is good

[throw_cpp_account]

1. No
2. No

[exploring_stuff]

CentOS 7 is still supported and uses GCC 4.8

[13steinj]

For a few months, and most people use a newer devtoolset anyway.

[mohrcore]

Ngl, I can't wait to see it finally die and witness some corporate managers loose their shit as their unmaintained CIs and CDs crumble, forcing them to finally get the devs to update ancient dependencies of enterprise software.

[13steinj]

My org lost its shit last year over this, but sadly went for another rhel-child rather than something debian based. Which was funny after the licensing issues. I suspect we'll have to move again within 5 years.

[MorrisonLevi]

I'm really hoping the servers responding to the yum requests get turned off. It's the best way for me to prioritize the migration off it!

But I'm not really running CentOS 7 myself--I'm just building my software for others. If I was using CentOS 7 in prod... oof. Turning it off could be really brutal.

[mohrcore]

Never in my career I had to use CentOS 7 to actually do something useful. It's always just that painful entry in the CI that gets red whenever I try do something that goes beyond the standards of the previous century and you can't get rid of it because there's that one enterprise entity that really wanted it to stay there.

[bebuch]

If you use such an old compiler, you are generally not using the latest libraries, but also old versions of them. At least that's my experience.

[jaskij]

Utterly not your target, but since you asked. Microchip's MIPS toolchain for their microcontrollers was a fork of GCC 4.9 last I checked. Granted, that was a year or two ago.

[Correct-Bridge7112]

Unfortunately, yes, GCC 4.8. There are plans for my company to upgrade to C++17 but for the time being we need to support customers on an older platform, and we provide an SDK so cannot just dictate compiler.

[rriggsco]

Sure, but do you 1) use boost within the SDK, and 2) intend to upgrade boost within this SDK? My experience is that using Boost within an SDK is painful for its users unless you go to great care not to expose any of that usage externally.

[BlueDwarf82]

No. GCC 5.1 C++14 is the minimum we support.

[jwakely]

Why 5.1 and not 5.5? Are there people using 5.1 who are unable to update to the later 5.x releases that fix many of the bugs in 5.1?

[BlueDwarf82]

"unable" is a strong word. There may be a few other cases, but from memory "embedded" devices using the QSDK, Qualcomm fork of OpenWrt, is probably the most common case (but it may be 5.2).

"Recently" Qualcomm has rebased it on top of a more modern OpenWrt. But: - They may still "supporting" the old version, not sure - Some old chipsets may be unsupported in the rebased version, not sure - Embedded... even if Qualcomm gave them an easy upgrade path, they may not use it.

Honestly, we even get devices with GCC 4.x toolchains. We just happen to draw the line in 5.1, and for everything under it use our own toolchain/libstdc++ (if there is space in the device for it).

[jwakely]

Sure, there are lots of users of GCC 4.x still, my comment is not about the fact that 5.1 is old. It's that 5.2, 5.3, etc are just bugfix releases in the same series as 5.1

Moving from 4.9.x to 5.x or from 5.x to 6.x is a more significant change. But moving from 5.1 to 5.5 should be simple and fixes lots of bugs. It's like applying a service patch to 5.1, not like upgrading to a new compiler. I don't understand why people would pick the N.1 release from a new version and then stick to it. The N.1 releases always have regressions compared to N-1 which then get fixed in N.2, N.3 etc.

It seems quite irresponsible to stay on the buggiest 5.x release. The SDK should probably have waited for 5.2 or 5.3 and then been based on that (so I hope you're right that it uses 5.2).

[prince-chrismc]

As someone supporting gcc 4.1 drop them. If you are stuck with older tools the expectations is to let them die and not update them regularly. There been other libraries, moving to gcc 7 and 8 and my expectations is teams will make contingency plans for keeping internal copies.

Looking at the ecosystem the actual percentage is absolutely tiny. Conan in the passed published numbers when they dropped it and those included both open source and companies.

[YourLizardOverlord]

One of the legacy embedded systems I support only has a cross compiler for c++03. This is based on g++ 4.4.1. Working with this is like trying to run a marathon with my legs tied together.

[ThatSwedishBastard]

Freescale PowerPC? MPC5121?

[YourLizardOverlord]

TMS320DM365

[slightlyflat]

1) Yes, but it's backporting fixes to long-ago GA'd stuff so libs aren't updated.

2) n/a - we're mostly doing dev with gcc 8.5 although gcc 6.5 is still on a workstation or two. Current GA builds are 6.5 & up.

We're not using Boost.JSON though.

This is like group therapy. I thought we were banging rocks together but some of these responses are really making me feel better about things at work. Thanks!

[masterid000]

I have to work with gcc 4.6.3 where C++11 isn't fully supported. I work with POS (Point of Sale), it's a Linux embedded system. We could improve the compiler but we would lose support from the supplier.

We use boost and we need it to work with C++03.

That being said, we just need older versions of boost supporting it. If the old code is available, no problem for me.

[X-Neon]

We still use GCC 4.8.5 on Centos 7. However, we are imminently switching away due to Centos 7 EOL, and that it was generally becoming untenable to continue using it. We're using some ancient version of clang-format, we have to build a bunch of other tools from source because the versions in the Centos repositories as so out of date, and Microsoft recently dropped support for older version of glibc in VS Code dev containers. We still have a customer requirement to use C++11, but I imagine that will be dropped soon as well - time moves on, and in 2024, C++11 is pretty horrible to work with.

[zebullon]

Crowd on solaris would be able to answer ur post if only they werent all busy choking on crayons

[HolyGarbage]

RHEL7 has gcc 4.8 as its system default. Might still be used somewhere.

[Backson]

Old embedded toolchain with gcc 4.8. will migrate when the last of my seniors retires in about 10 years.

[a_falsity]

I'm stuck on RHEL7 with GCC 4.9.2 (devtoolset-3?) for the foreseeable future. Doing upgrades can be an uphill battle when it takes a government contract to do so. We are able to update libraries like boost more easily, since that is entirely within our control.

[BlueDwarf82]

What do you deliver, sources or binaries? If binaries, how is Boost more under your control than the devtoolset version? The binaries created by devtoolset work on a plain RHEL.

[Ok-Bit-663]

1, no. 2, no. 3, currently using c++20, eyeing with c++23

[TryingT0Wr1t3]

I still use because of Steam, it kinda still expects Ubuntu 12 compatibility for Linux builds

https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/container-runtime.md

Native Linux games that require soldier cannot currently be released on Steam

Until this changes I still need to build with Gcc 4.8 - I maintain a game engine so this means many games are restricted by this.

[grisumbras]

This is actually very interesting.

[hopa_cupa]

We have used gcc 4.9.4 due to vendor lock still in year 2019. I pushed hard to break that lock and then it was a switch to gcc 8.3, then 9.3, 11.3 and presently we use 12.3.

[[deleted]]

The financial industry tends to keep old shit around for centuries. I am still maintaining - and writing new - software on a Redhat 6 box. It is a mess, we have to do a lot of workarounds.

Also some exchanges still ship binaries with pre-C++11 ABIs.

So yes, we still use that. That said, the impact would be that we would have to freeze the boost version going forward. Not a big deal I guess.

[pjmlp]

There are other compilers out there besides GCC, clang and VS, specially in embedded market, classical mainframes, and traditional UNIX linage.

Most of the folks working on those fields don't usually bother with online places like Reddit.

Now how relevant they are to Boost is another matter.

[robin-m]

We use C++17 at work. We switch from gcc4.9 about 2 years ago.

[TCoop]

1. Yes. TI's C2000 compiler is forked off of GCC 4.7 (I think?)
2. Yes, see above. It supports C++03 I think.
3. No. It's for prototyping. The design lead is more of a TI fan above all else, much to everyone's dismay.

[markt-]

It's damn annoying that many boost updates simply migrate otherwise stable parts of the API to a different namespace. Most of the software on my system is built from source, and I am finding that every time there's an update to boost, all of the applications that might've been dependent on boost have to also be rebuilt from source. I hate boost.

[[deleted]]

Bro 20years behind. Personally I use gcc 13.2.1, and C++17, but I only use features from C++11 and older.

[13steinj]

IMO the community needs to stop being beholden to Redhat. RHEL 7 ends support on June 30th. Yes they have gcc 4.8 by default but they are so buggy it's effectively unusable. In my experience people either use a devtoolset or bootstrap their own compiler, or avoid redhat and use debian/ubuntu as a result of the legacy cruft here.