Downgrade gcc to 4.9

[starius]

See #964
See da82d07
See c96a007
See 7882944

[tonytheodore]

I'm not sure this is a good approach as we'll never know when we can upgrade. I think it's better to investigate further and submit upstream reports.

If someone wants to lock a gcc version, plugins are a better way to manage that, and if we can isolate a specific issue (say -fno-devirtualize) then we can control that with spec files.

[starius]

libmysqlclient is broken for this pull request (log).
It can be interesting even if we won't downgrade to 4.9.

[starius]

as we'll never know when we can upgrade

When gcc-5 becomes stable. Stable releases of Linux distributions (Debian, OpenSuse, gentoo) use gcc <= 4.9. A bug in compiler is a bug in every other package. Branch 5 of GCC has too many bugs. Bugs in gcc-5 keep being detected and fixed. If we want gcc-5, we should track and backport all reported bugs carefully, as Debian maintainers do. Gcc 4.9 is less buggy than gcc 5. Does any package in MXE use features of gcc-5 not available in gcc-4.9?

[tonytheodore]

When gcc-5 becomes stable. Stable releases of Linux distributions (Debian, OpenSuse, gentoo) use gcc <= 4.9

It's a bit of chicken-and-egg, how will it become stable if the major distros don't give it exposure? gcc 4.9 also had issues earlier in it's cycle.

Does any package in MXE use features of gcc-5 not available in gcc-4.9?

Very unlikely, it would be the latest versions if so and many packages need updating. We've spent more time chasing down bugs than looking at those ;)

From the gcc homepage it looks like gcc-6 is already in the works and the 5 series may not have a very long life. If no one objects in the next day or so I'll merge this and see about making the 5 series a plugin.

[mabrand]

My doubts are in line with Tony's first comments on this. Ubuntu 15.10 uses gcc 5.2.1 which suggests that gcc 5 is at least somewhat reliable.

#964 mentions the possibility that gcc-1.fixes could be to blame. Shouldn't that be investigated first anyway?

Does any package in MXE use features of gcc-5 not available in gcc-4.9?

I'm not sure this should be the deciding criterion. Whether or not MXE packages already exploit gcc 5 features, users of MXE might very well be interested in the features and improvements of gcc 5.

I think the criterion for downgrading should be whether programs are much more likely to be broken by gcc 5 than gcc 4. The fact that Ubuntu 15.10 has adopted gcc 5 makes it seem doubtful that this is the case. Are the problems with gcc 5 much more likely to affect mingw than linux?

[starius]

#964 mentions the possibility that gcc-1.fixes could be to blame. Shouldn't that be investigated first anyway?

The reason is the gcc bug. The MXE patches do not affect this bug.

This bug was erroneously marked as a duplicate of another similar bug, but the fix proposed for that bug doesn't fix compilation of my code. The bug has not been updated for a week. It is typical for a development branch not for stable.

There is another bug mentioned in the mailing thread, which seems to be an unrelated bug in gcc.

Ubuntu 15.10 uses gcc 5.2.1 which suggests that gcc 5 is at least somewhat reliable.

Unfortunately Ubuntu often updates packages to unstable version too early. New Ubuntu releases (e.g., Ubuntu 15) are based on Debian Sid (=unstable). Stable and testing Debian releases use gcc 4.9.

As an example, Travis CI uses old Ubuntu with gcc 4.6 (or optionally Ubuntu 14 with gcc 4.8).

I think the criterion for downgrading should be whether programs are much more likely to be broken by gcc 5 than gcc 4.

There are at least two real cases when a program of MXE user is broken because of not fixed gcc-5 bug. I know no such cases for gcc-4.9

[mabrand]

I'm satisfied with that explanation. Writing software is hard enough when you can trust the compiler.

[starius]

libmysqlclient fixed

[starius]

PR rebased

[starius]

Help needed with c96a007#commitcomment-14323213

[starius]

I'm building commit 44ad791

[starius]

Commit 44ad791 was built. No errors occurred.
https://gist.github.com/starius/d23568a542766398bc6f

[tonytheodore]

Great! Thanks for all your work on this - in the absence of a stable branch, the core toolset will benefit from a slower cycle and will give us some leeway to work on infrastructure and packages to make the overall MXE experience better.

[tm604]

Note that gcc < 5.0 means some C++14 features will no longer be available:

https://gcc.gnu.org/projects/cxx1y.html

of these, the one I use most is the variable templates support. Supporting a stable version of gcc seems like a sensible goal, just concerned that rolling back to 4.9 after so long with 5.0+ being available is quite a big step backwards.

Having gcc5 available via config, separate package or plugin support would be great if that's possible?

[tonytheodore]

Having gcc5 available via config, separate package or plugin support would be great if that's possible?

Yes, it's certainly possible and on the short-term agenda - the main issue is which of those options is the most suitable?

[tm604]

Having gcc5 available via config, separate package or plugin support would be great if that's possible?
Yes, it's certainly possible and on the short-term agenda - the main issue is which of those options is the most suitable?

I don't think gcc5 is ABI-compatible with 4.9, so I'd guess that a separate package would introduce some problems of its own. Perhaps either a variable like MXE_GCC_VERSION (similar to MXE_GCC_THREADS) or a separate MXE_TARGET would be more appropriate?

[avih]

Great! Thanks for all your work on this - in the absence of a stable branch, the core toolset will benefit from a slower cycle and will give us some leeway to work on infrastructure and packages to make the overall MXE experience better.

Hmm... maybe this would be a good opportunity to create a stable branch again? Or approach it by using "subject-specific experiments" branches (in this case - GCC 5 branch)?

Possibly with some well defined policy to keep the branches as close to identical as possible, except for the subject being experimented with (GCC 5 here, maybe something else in the future too), with a stated goal to merge them as soon as possible?

Afterall, MXE's approach has been to pretty much to take newer versions of packages quite early. That being said, I do agree that the build tools/compiler could benefit from a more conservative approach.

But still, I think GCC5 should stay a possibility with MXE, since presumably sooner or later it will be the main compiler anyway.

[tonytheodore]

Perhaps either a variable like MXE_GCC_VERSION (similar to MXE_GCC_THREADS) or a separate MXE_TARGET would be more appropriate?

At the moment, I'm leaning towards both a variable and a pseudo target in relation to #961. My WIP so far has normal MXE targets depending on a toolchain target along the lines of i686-w64-minw32.multi. I'm no longer using the multi-lib approach, so these can be along the lines of:

i686-w64-mingw32.gcc49
i686-w64-mingw32.gcc52
i686-w64-mingw32.clang

Normal use would be a variable like MXE_USE_CC, people building side-by-side (say for testing) would use i686-w64-mingw32.static.posix.gcc52 etc.

Possibly with some well defined policy to keep the branches as close to identical as possible, except for the subject being experimented with (GCC 5 here, maybe something else in the future too), with a stated goal to merge them as soon as possible?

This is much easier to do with selectively overriding rules via a "plugin" mechanism (#935). There's no merge conflicts and experiments can be very long-lived. You can also do multiple experiments simultaneously which requires a lot of mental housekeeping to do with git.

[tonytheodore]

See 5e63e41.

It's the simplest thing that works, no side-by-side, alternate targets, or spec files. You can test this with:

make MXE_PLUGIN_DIRS=plugins/gcc52