Hello wine-devel,
I wanted to follow up on the discussion on https://gitlab.winehq.org/wine/ wine/-/merge_requests/3059
For those not in the loop: The question came up what GCC version is the oldest supported one, and which language features can't be used in Wine.
Is there already a wiki entry on this?
Associated bug report: https://bugs.winehq.org/show_bug.cgi?id=54601 (Compilation fails with gcc 4.3.4 (error: unknown field ‘Type’ specified in initializer)
I have a bunch of gcc 4.3 patches, and if it's supported, I think it would be useful getting those in before the next stable. Although ongoing gcc 4.3 support is probably a bit of work, since most people don't test against gcc 4.3 compatibility so there's some "regressions" from time to time. An option would be to just patch it when someone complains, which would be the most reasonable to me. Or just cap it at 4.8 which currently works. In the end, some compiler will be too old, so where is the line?
In a similar vein, what about https://bugs.winehq.org/show_bug.cgi?id=20474 (Wine can't be built with GCC in C99 mode) Is this a supported setup? IMHO itwould be too much effort work to get this working, but I don't make the decisions.
Regards, Fabian Maurer
Hello,
On 11/12/23 03:34, Fabian Maurer wrote:
https://wiki.winehq.org/Gcc 4.4 and older has a non working ms_hook_prologue
Enterprise Linux distributions were considered kinda the drivers for supporting old compilers: SLES 12 and RHEL 7 already come with gcc-4.8; no clue what the latest supported stable Ubuntu version is but assuming it is newer.
My vote is to bump up the supported version to 4.8.
Well -std=gnu99 and -std=gnu11 already work according to that bug report. It is just the pure C standard that isn't working. We had this topic afair repeatedly on wine-devel and WineConf. Consensus was that Wine has to support real life compilers and not arbitrary C pure standard versions.
bye michael
On Sun, 12 Nov 2023, Fabian Maurer wrote:
For those not in the loop: The question came up what GCC version is the oldest supported one, and which language features can't be used in Wine.
I recommend we do not cater to versions of GCC that have been end of life for an extended period of time.
GCC 4.3 went end of life mid 2011.
Or just cap it at 4.8 which currently works.
GCC 4.8 went end of life mid 2015.
The oldest GCC release series I would remotely consider supporting is GCC 8 which wend end of life mid 2021, though it's really not unreasonable to focus on GCC 11 and later.
Gerald
On 12/11/2023 23:03, Gerald Pfeifer wrote:
Sorry, what? Some distros have 10 year long-term support. Not everything is rolling release, nor should it be, not even close.
I mean, compiling or backporting compilers isn't that big of a deal but the main problem with new compilers on old platforms is that you might need new core libraries (libc, libstdc++, etc) because of how GCC works. Having multiple libc side-by-side is difficult, and updating such a core component in a stable distro is way too much to ask.
On Mon, 13 Nov 2023, Gabriel Ivăncescu wrote:
I know.
In fact I happen to work for one of the Linux distros with the longest, if not the longest, support cycles.
We (SUSE in this case, and I believe it similarly holds for Red Hat) do provide newer toolchains for older distros. And we do so in a way that users are fully covered and don't need to build or replace system components on their own.
Having multiple libc side-by-side is difficult, and updating such a core component in a stable distro is way too much to ask.
libc generally isn't affected, though we have been updating it in some cases, and we take care of the default run-time libraries to be suitable for both the older and newer toolschains. (The GNU toolchain puts quite some focus on backwards compatibility of run time components.)
Gerald
On Sun, 12 Nov 2023, Gerald Pfeifer wrote: [...]
Here are some data points coming from the other side of the equation: what gcc versions do Linux distributions ship?
Then pick the oldest Linux distribution you want to support and that tells you which gcc version to support.
Debian 5 gcc 4.3 Debian 6 gcc 4.4 Debian 7 gcc 4.7.2 Debian 8 gcc 4.8.4 Debian 9 gcc 6.3.0 Debian 10 gcc 8.3.0 Debian 11 gcc 10.2.1 Debian 12 gcc 12.2.0
Ubuntu 14.04 LTS gcc 4.8.2 or 4.9-20140406? Ubuntu 16.10 gcc 6.1.1 (I don't have the 16.04 LTS data) Ubuntu 18.04 LTS gcc 8.2.0 Ubuntu 18.10 gcc 8.2.0 Ubuntu 19.04 gcc 8.3.0 Ubuntu 19.10 gcc 9.2.1 Ubuntu 20.04 LTS gcc 9.3.0 or 10-20200411? Ubuntu 20.10 gcc 10.2.0 Ubuntu 21.04 gcc 11.1.0 Ubuntu 21.10 gcc 11.2.0 Ubuntu 22.04 LTS gcc 11.2.0 or 12-20220319? Ubuntu 22.10 gcc 12.2.0 Ubuntu 23.04 gcc 13.1.0 Ubuntu 23.10 gcc 13.2.0
Fedora 31 gcc 9.2.1 Fedora 32 gcc 10.0.1 Fedora 33 gcc 10.2.1 Fedora 34 gcc 11.0.1 Fedora 35 gcc 11.2.1 Fedora 36 gcc 12.1.1 Fedora 37 gcc 12.2.1 Fedora 38 gcc 13.0.1
RHEL 6.8 gcc 4.4.7 RHEL 7.8 gcc 4.8.5 RHEL 8.1 gcc 8.3.1 RockyLinux 8 gcc 8.5.0 AlmaLinux 9 gcc 11.2.1
openSUSE 15.1 gcc 8.2.1 openSUSE 15.2 gcc 9.2.1 openSUSE 15.3 gcc 10.3.0 openSUSE 15.4 gcc 11.3.0
So: * Pick gcc 4.8 for Debian 8 and RHEL 7 support. * Pick gcc 6.3 for Debian 9 support. * Pick gcc 8.2 for most Linux distributions: Debian 10 openSUSE 15.1 RHEL 8 Ubuntu 18.04 LTS
Am 13.11.23 um 16:48 schrieb Francois Gouget:
Thanks for the data points. Let me reduce them to the only distributions with long term support for old compilers:
For Debian we shouldn't care about anything before 8. And RHEL 6 has EOL in June 2024. So IMHO there's no benefit in caring about gcc < 4.8, but 4.8 is worth a discussion.
For Debian we shouldn't care about anything before 8. And RHEL 6 has EOL in
June 2024.
So IMHO there's no benefit in caring about gcc < 4.8, but 4.8 is worth a
discussion.
Seems sensible to me. IMHO an official decision would be helpful, though. Would it make sense to have configure give an error when your compiler is too old?
Regards, Fabian Maurer
André Zwing nerv@dawncrow.de writes:
Our policy is to not draw arbitrary lines of supported/unsupported. That's true for C standard versions, compiler versions, distros, window managers, graphics cards, etc.
We want to support what our users are actually using. If someone reports an issue with their compiler, we want to look into it. We are not going to reject a report because the compiler is "too old", or out of maintenance, or on a distro we've hever heard of.
That doesn't mean we have to fix everything, there's always a trade-off between the complexity/ugliness of the fix, the number of affected users, the availability of a workaround, etc. But that should be decided based on the actual issue, not on some arbitrary version number cutoff.
So it may be that we want to require support for typedef redefinitions, because avoiding them is ugly. In practice, that would mean that you can't build with gcc 4.3 out of the box. But it does not mean that gcc 4.3 is somehow "unsupported". If someone reports some other issue with gcc 4.3, and that one is easy to fix, we'll still want to fix it.
On Sat, Nov 11, 2023 at 7:34 PM Fabian Maurer dark.shadow4@web.de wrote:
Don't forget that it should be possible to compile Wine's PE modules with MSVC too. Microsoft supports each MSVC release for 10 years,[1] and Wine uses designated initializers which MSVC has supported since 2013,[2] so we are currently supporting about the same range of versions as Microsoft does.
Is there already a wiki entry on this?
Yes, I rewrote the relevant parts of the wiki after the discussion on merge request !3059, particularly https://wiki.winehq.org/Wine_Developer%27s_Guide/Coding_Practice#Writing_por...
It needs to be updated again to document what Alexandre explained today.[3] I'm happy to do that, but it might be a few days before I get to it because my to-do list is _very_ long right now.
-Alex
[1] https://learn.microsoft.com/en-us/visualstudio/productinfo/vs-servicing [2] https://learn.microsoft.com/en-us/cpp/porting/visual-cpp-what-s-new-2003-thr... [3] https://www.winehq.org/mailman3/hyperkitty/list/wine-devel@winehq.org/messag...