Comment by jcelerier | Hacker News Reader

Comment by jcelerier | Hacker News Reader

Parent Full thread

> If you were a C++ developer, would you request C++17/C++20 also?

yes absolutely. I think that it is wild that some people stay with older compilers solely because they happen to be on an old distro and don't want to update. Tying compiler versions to operating system versions is absolutely braindead. A compiler is just a program that takes text and outputs a binary which is supposed to work on anything with the expected ABI - you could even cross-compile from windows if you wanted ; at least I've done the opposite (cross-compile windows binaries from a linux host) a few times.

e.g. personally I mostly use clang-13, soon 14, for development with every possible C++20 goodies, and ship software that works back to windows 7, mac os 10.13 and until recently centos:7-era linux userland (recently upgraded to 8). There is zero reason to use an older compiler.

> I don't know why GCC-12 was in the picture, but I hope all of you can understand one thing: python's source code must be compatible with GCC 6. And no so called "Threading [Optional]" features. It is all because CentOS is dead. CentOS has been sold to IBM. There is no CentOS 8 anymore. The free lunch is ended. And there wouldn't be another OSS project to replace it.

the day centos:8 ended I replaced centos:8 with rockylinux:8 in my docker image for my builds and everything continued working fine with the latest GCC and Clang versions.

Honestly your pains regarding gcc-6 are entirely self-inflicted. Just ship a more recent GCC binary with the manylinux project or something, you can build it on centos 5 if you fancy in order to get it to work on older libcs

I agree, and especially in the context of Python. My Mac comes with Python 2.7 and 3.8, but it seems like almost everyone uses Homebrew or pyenv to locally install a newer version. I rarely hear of anyone going out of their way to stick with the system version outside of specific scenarios (like "IT locks down developer laptops") or such.

And while I'm keenly aware that Python and C++ are very different languages, if someone asked if I'd insist on using the "new" Python17 (aka 3.6), like that was wildly and unreasonably bleeding edge, I'd literally laugh at them.

If everyone just use the latest macOS and the latest iOS, I'm less concerned. But I haven't heard any IT manager enforcing that. macOS 12 has come out, but usually they still allows you using macOS 11 as long as you have installed all the security bug fixes.

For macOS and iOS, the problem is more complicated. Let's say I want to publish a package to pypi.org. The package contains some binaries compiled from C++ and it requires C++17. Then what is the lowest macOS version the binary can support?? It's very tricky that if the build machine which generates the package is macOS 11, then it can have Xcode 12.5. Otherwise it has to use XCode 12.4 or lower. And in XCode 12.4 it says std::optional, which is a C++17 feature, is only supported in macOS 10.14+. But if the build machine has macOS 11 and XCode 12.5, then the binary would be able to run on 10.13 too. And in whatever case, it can't support 10.12 or lower.

I believe you don't want to build tensorflow/pytorch packages from source. So the maintainers of these two OSS projects must consider the things above. If you wonder why they don't use C++17, this is the reason. For the same reason they want to avoid C11 optional features too.

Thanks for the info. Would there likely be a downside to saying "if you want to use the precompiled packages, you need to be on macOS 11+ (but feel free to DIY if you're stuck on an older version)"?

> Then what is the lowest macOS version the binary can support??? It's very tricky [...]

No it's not. The oldest supported version of macOS your binary will run on will be the one you set in your CFLAGS with the -mmacosx-version-min=10.x flag when you build.

The OS you are running the build on and the Xcode version don't influence that, you should just run the most recent Xcode you can, build against the most recent macOS SDK available and set that flag. You can target 10.8 from Big Sur and Xcode 12 with afaik no issues.

> The OS you are running the build on and the Xcode version don't influence that

Usually it doesn't. But in this special case it does. I have set the flag you said. When C++17 wasn't in the picture, it's enough. But now we are talking about how to enable developer using the new language features. New C++ features typically need new runtime. But the old systems do have it. Then one of the difficulty is how to figure out which macOS versions have it, which doesn't.

The std::optional / std::variant case is unfortunate indeed, it's sadly an argument for using non-std versions of these types. It's also possible to cheat a bit with libc++ macros.. -D_LIBCPP_NO_EXCEPTIONS=1 does the trick (but turns exceptions into asserts).

You can also link statically against libc++.

So you are conflating tons of things here and none of it really makes sense. The reason why compiling for macOS tends to claim stuff like how C++ features are tied to operating system targets is because Apple doesn't really understand how to do toolchain architecture well and so have managed to do this awkward thing where the operating system--from their perspective--is this massive monolithic brick that contains a ton of functionality that is classically introduced by the toolchain, which I admit has some advantages but generally feels ill-intentioned.

The result of this is that Apple really assumes you are going to use the copy of libc++ that ships on the system, and it might be missing exported systems that are assumed by the library. But this isn't related to the toolchain you are using. I do remember some weird corner case with std::optional and I think it might have been that Apple forgot to mark something correctly as unsupported in a previous toolchain build? The newer compiler is thereby actually giving you the more correct understanding of what can actually be presumed to work on older systems.

But like, the core issue here is that you really shouldn't use Apple's stupid toolchain setup, nor do you have to: just embed your own copy of libc++ and call it a day. I routinely use the latest versions of Xcode's copy of clang (though I prefer to compile for macOS now using the copy of clang that comes with the Android NDK for various reasons: I recommend avoiding Xcode except to get their system headers) to target ancient systems with modern C++ features as I'm not relying on the system copy of libc++ to even exist or work (10.7's doesn't) much less be complete.

I agree that there is little reason to not use a newer compiler to target an older distro, but there is one issue: the standard library. With newer language versions the standard library also grows. Older distros ship with older standard libraries, and they probably don't have the newer language facilities in them.

At work we sidestep this by building the new C++ standard library implementation against an old libc, and ship it with our product. I can imagine that this could be problematic for other software though, especially ones that normally ship with the disto.

> I can imagine that this could be problematic for other software though, especially ones that normally ship with the disto.

why would it be an issue ? that's how pretty much every software does on Windows and most certainly people can agree that things are much more sane there for the end-users

This is not a technical issue. But if you aim for the software to be packaged in official distro repositories, they possibly don't want you to have other backported dependencies, such as a new version of libstdc++, or you to vendor in those libraries.

In practice compilers and the things they compile are insanely large. If we started updating them more... who knows what bugs we'd get with different GCCs on different OSes...

Up-to-date Linux distros already compile things with latest compilers. The bugs are already caught there. And in my experience, with GCC and clang, updating to new versions consistently reduces bugs.

Reply on news.ycombinator.com