4 ms·

> 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 be

> 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

kstrauser 5y ago
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.
- snnn 5y ago
  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.
  - kstrauser 5y ago
    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)"?
  - jcelerier 5y ago
    > 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.
    - snnn 5y ago
      > 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.
deleted 5y ago
[deleted]
eternityforest 5y ago
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...
- jcelerier 5y ago
  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.
steerablesafe 5y ago
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.
- jcelerier 5y ago
  > 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
  - steerablesafe 5y ago
    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.

kstrauser 5y ago

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.

snnn 5y ago
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.
- kstrauser 5y ago
  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)"?
- jcelerier 5y ago
  > 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.
  - snnn 5y ago
    > 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.

deleted 5y ago

[deleted]

eternityforest 5y ago

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...

jcelerier 5y ago
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.

steerablesafe 5y ago

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.

jcelerier 5y ago
> 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
- steerablesafe 5y ago
  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.