12 Nov
2023
12 Nov
'23
2:34 a.m.
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
12 Nov
12 Nov
6:05 p.m.
Hello,
On 11/12/23 03:34, Fabian Maurer wrote:
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?
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.
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?
My vote is to bump up the supported version to 4.8.
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.
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
9:03 p.m.
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.
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.
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
13 Nov
13 Nov
3:41 p.m.
On 12/11/2023 23:03, Gerald Pfeifer wrote:
On Sun, 12 Nov 2023, Fabian Maurer 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.
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.
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.
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
22 Nov
22 Nov
9:53 p.m.
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.
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.
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.
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
13 Nov
13 Nov
3:48 p.m.
On Sun, 12 Nov 2023, Gerald Pfeifer wrote:
[...]
On Sun, 12 Nov 2023, Fabian Maurer 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
--
Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/
Hiroshima '45 - Czernobyl '86 - Windows '95
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. 
7:42 p.m.
Am 13.11.23 um 16:48 schrieb Francois Gouget:
On Sun, 12 Nov 2023, Gerald Pfeifer wrote:
[...]
Thanks for the data points. Let me reduce them to the only distributions with long term
support for old compilers:
On Sun, 12 Nov 2023, Fabian Maurer 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. 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. 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
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
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.
14 Nov
14 Nov
12:15 a.m.
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
10:20 a.m.
André Zwing <nerv(a)dawncrow.de> writes:
Am 13.11.23 um 16:48 schrieb Francois Gouget:
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.
--
Alexandre Julliard
julliard(a)winehq.org
On Sun, 12 Nov 2023, Gerald Pfeifer wrote:
[...]
Thanks for the data points. Let me reduce them to the only distributions with long term
support for old compilers:
On Sun, 12 Nov 2023, Fabian Maurer 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. 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. 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
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
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. 
5:46 p.m.
On Sat, Nov 11, 2023 at 7:34 PM Fabian Maurer <dark.shadow4(a)web.de> wrote:
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.
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_po…
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-th…
[3]
https://www.winehq.org/mailman3/hyperkitty/list/[email protected]/messa…
173
days inactive
183
days old
9 comments
8 participants
participants (8)
-
Alex Henrie -
Alexandre Julliard -
André Zwing -
Fabian Maurer -
Francois Gouget -
Gabriel Ivăncescu -
Gerald Pfeifer -
Michael Stefaniuc