Hi all. I have my own personal slackrepo build system up and running for the last year. I have been tracking slackware64-current and my build system for building mythtv has been flawless. However, after the recent upgrade to gcc 7.1.0 I am unable to build mythtv.

I see the following repeatedly before it dies.

/tmp/mythtv/mythtv-0.27.6/mythtv/libs/libmythui/mythdialogbox.h:52: Parse error at "defined"
make[2]: *** [Makefile:524: moc_myththemedmenu.cpp] Error 1

Nothing has changed in the source code. The version is 0.27.6 and has not had an update to the code in 6 months. So, I know it is not a code change

I also tried rebuilding the Qt4 version from Slackware64-current source and it fails as well. I suspect QT and QT based apps are not liking the current version of gcc in Slackware64-current.

Has anyone else seen an issue like this?

I think it's normal because qt package was lastly updated at Wed Sep 21 15:54:06 UTC 2016.

it's pretty much normal as gcc becomes more and more stricter about the code it accepts.

there has been a jump from version 5.x to version 7.x so these are the changes that developers have to take in account
https://gcc.gnu.org/gcc-6/porting_to.html
https://gcc.gnu.org/gcc-7/porting_to.html

it looks like the mythtv ones already did for their latest stable release as its 0.28.1 version, that uses qt-5.x instead of qt-4.x (so it needs the qt5 package), builds fine here on slackware64-current.

I have a build repo I am in the process of getting finished for building MythTV 0.29. I am waiting for Myth to finalize before moving to this repo.

Ponce, Your comments make me wonder if Pat is ever going to go to Qt 5 and the Plasma desktop. I would prefer to use as much official packages as possible.

Thanks for the links. I will see what I can do. I figured I would have to do something with the compiler options. It was getting late for me and decided to see what help I could get via the forums.

I imagine this is going to occur this development cycle, especially since KDE4 is no longer developed. Eric already has working Plasma 5 packages in his ktown repo, so it will just be a matter of Pat making the decision to switch.

Not to hijack this thread, but some other examples of gcc 7.1.0 issues are...

1. bsnes-mercury and bsnes-libretro get stuck indefinitely on the following command with '-O3' which is default in the Makefile and upstream higan doesn't remotely compile anymore although that was rather broken to begin with.
https://github.com/libretro/bsnes-mercury/issues/47

2. pcsx2 was hit especially hard and now segfaults when opening various menus in the frontend.

https://github.com/PCSX2/pcsx2/issues/1935

3. The OpenGL gsdx plugin is also entirely non-functional...

https://github.com/PCSX2/pcsx2/issues/1937

1 members found this post helpful.

This makes me think I should test some of the stuff I've written with this new gcc version.

1 members found this post helpful.

GCC 7.1.0 is currently used only in a small number of distributions so not all projects are tested with the new GCC. So far, only LFS, Fedora, Ubuntu Snapshot, and Gentoo Unstable that have shipped GCC 7.1.0 besides Slackware-Current.

It will take time before other projects can catch up with the GCC latest release.

You pointed exactly WHY a distribution should NOT ship the latest mightiest GCC release.

Just because will take time before other projects can catch up with the GCC latest release.

I hope NOT, especially while KDE4 could be patched.

Guess what, Slackware-current is a development branch. It isn't to be used in a production environment where these gcc issues can bite you. Hopefully by the time the next stable is released, gcc7 support in 3rd-party projects will have matured.

Yeah, but who's going to do the patching? XFree86 can be patched too, but nobody's doing it.

6 members found this post helpful.

The bad news is that Slackware have the habit to stay on top version of GCC until last minute, so your claim does not apply...


Overall, I believe that could help lurking to what CentOS do, instead to look to Arch Linux like a fanboy to a Rock Star...

I believe when the next Slackware gets released, GCC is tamed
We haven't heard Patrick calling for Beta 1. Even with Beta 1 announced, the final released is still months away (14.2 was released about 5 months after Beta 1 was announced).

What matters is that core packages are correctly built because that will be the base for third party packages or repository such as SBo or any other personal repositories.

As for KDE 4, with more and more packages are being ported to KDE 5, using KDE 4 for next release which will be supported for at least 5 years is not the best idea. People who wanted to keep using KDE 4 can still be using Slackware 14.2. It's their choice. No one is forcing users to migrate to newer version of Slackware every time a new release is available.

2 members found this post helpful.

Now I use Slackware 14.1 for stable uses, current for playing with. Hoping that I can use 14.3, through...

We are not sure whether the next version will be called 14.3 or 15.0 or probably jump to another version. I guess we will have to wait for that