protobuf: build with c++14

[happysalada]

Description of changes

the readme explicitely states that protobuf should be built with c++14.
I was wondering if this was a discussion that was made before.
Is there a reason not to ?
should we use c++17 ? I'm not sure if it will have some impacts downstream ?
(I know that if this is merged, it will have to be merged on staging, but I'm opening this PR to discuss the idea).
@acairncross is the one who noticed it.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.11 Release Notes (or backporting 23.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[tobim]

This is not a good idea because you will also have to build abseil-cpp with c++14, and since that is a propagated input you will also have to build all reverse dependencies that make use of abseil in c++14 mode. Many of those don't even support c++14 any more.

The readme simply makes a poor statement there, it should really say c++14 or later, c++ goes to great lengths to preserve backwards compatibility after all.

[acairncross]

@tobim To clarify, my comment was why (or how, even) we were compiling protobuf without specifying any C++ version at all, making me assume we're using a pretty old C++ version yet somehow able to compile protobuf.

However, I've just looked through the docs of g++ and it turns out gnu++14 is the default C++ version, so in fact we are compiling with C++ 14 after all.

[tobim]

However, I've just looked through the docs of g++ and it turns out gnu++14 is the default C++ version, so in fact we are compiling with C++ 14 after all.

It is actually c++17, to which it was bumped with GCC11: https://www.gnu.org/software/gcc/gcc-11/changes.html.

You can check your own compiler with

❯ g++ --version
g++ (GCC) 12.3.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

❯ g++ -dM -E -x c++  /dev/null | grep -F __cplusplus
#define __cplusplus 201703L

[tobim]

Note that the situation is different in when stdenv.cc is clang, because our default clang version is very old (llvm11). Setting c++14 in that situation should be fine, because it is not a downgrade from C++17.

[acairncross]

It is actually c++17, to which it was bumped with GCC11

Ah I see, that clears up quite a few things for me, thanks! (I had been looking at the man pages in a nix-shell which wasn't for the right version of g++.)

[happysalada]

@tobim I've made the change you suggested, on darwin stdenv.cc defaults to the old clang, so protobuf would build with c++14 by default only on that platform.
let me know if that works for you and I'll make a PR to target staging.

[tobim]

I have checked the clang release notes again and found out that all versions from 6 to 15 default to C++14. Sorry for misleading you.

I just opened #255979 to allow a somewhat simpler approach to this kind of problem.