Comment by wfunction | Hacker News Reader

Comment by wfunction | Hacker News Reader

Parent Full thread

> The downside, of course, is just how much code exists that is written in pre-C++11 dialects, and how many programmers are trained to write that sort of code.

I do the same thing. Not because I can't write C++11, but because I still encounter systems with older compilers that I want to run programs on. What, is this surprising?

Let's face reality: it's a little unreasonable to expect every system you work on to have a compiler less than 3 years old.

Especially true on older Linux systems, it's sometimes a massive pain or even pretty much impossible to upgrade the existing compiler in a package-manager-friendly way (try upgrading Ubuntu 12.04's compiler to GCC 4.9, for example), so you'd have to compiler the compiler from scratch. Which is a pretty massive PITA and more or less requires a PhD of its own for GCC (Clang is a little better). And on Windows VC++ isn't always exactly following the correct standard. It's not necessarily outright impossible, but it's pretty impractical.

> Let's face reality: it's a little unreasonable to expect every system you work on to have a compiler less than 3 years old.

If you are running Linux, this is one thing that Windows gets right. (Although as you say VC++ has some catching up to do still).

Linux is on all parts of the spectrum here. Ubuntu LTS and Slackware are going to remain outdated by design. Arch Linux almost always have the most recent stable releases of GCC and clang, and you can even build development snapshots from AUR

You don't need to use the compiler from the distro to release for that distro. There is such thing as cross compilation after all. Most do it out of habit and because distros don't offer such services out of the box. But if you build the cross compiler, you can use the newest one even if the distro ships the older.

For example I had a building machine running RHEL 5 which was building for both RHEL 5 and RHEL 6 while using gcc 4.8.2 for both (cross compilers).

You say "if you build the cross-compiler" as though it's as simple as "if you cross the street". Have you ever tried building GCC? I've wasted days on it and in the end still failed to make it work.

It is hard if you do it all manually. There are helpful tools like Crosstool-NG for example which make it easier.

See also https://en.wikipedia.org/wiki/Cross_compilers#External_links

> Have you ever tried building GCC? I've wasted days on it and in the end still failed to make it work.

I've hand-built GCC for half a dozen of different target architectures over the years and it's perhaps one of the most stable pieces of software when it comes to building it. I've only had one build failure over the years and that was unstable from git (even that usually works no problem).

To build GCC, follow the simple steps on the GCC manual. With a modern fast computer, it's all done in an hour or two (of mostly waiting).

I don't know how you manage it, but I can tell you it is not reasonable to expect people to compile every compiler they want to use on every system they want to use it.

> I don't know how you manage it, but I can tell you it is not reasonable to expect people to compile every compiler they want to use on every system they want to use it.

If you're dealing with bare metal projects (kernel programming or micro controllers), building binutils and gcc for cross compiling from source is pretty much required. There are scripts that help and some distros have cross compilers in their package managers.

But building GCC is not difficult and it pretty much works first time, every time.

No one implied people are expected to compile every compiler they want to use on every system they want to use it. Point was it's not hard. Maybe link to a message where you detailed your troubles?

Heh! I am stuck on VC++ 2010 at work. I gaze longingly at C++11 features but can't use them. A pity, as the same codebase is also built under XCode and Clang.

> upgrade the existing compiler in a package-manager-friendly way

This is your problem.

Build a new compiler using the old compiler and install the entire new toolchain in /opt/my-gcc-4.9-0xfoof . rsync this new compiler to any machine you want. The package managers (people and code) a here for our suffering.

When LLVM started to require C++11 (which we use as a library), my team decided to statically link libstdc++ into our product on Linux. Now we just depend on glibc (and we use symbol versioning to keep the required version to a minimum). It sounds like you ship source though, so it may not be an option for you.

Reply on news.ycombinator.com