sse2 dependency for qt5; Slackware's roadmap?
 

Hello all.

It appears QT5 is now requiring sse2 by default on gnu/linux.

Some distro's are disabling this requirement at this time; but the future is as always uncertain.

Does anyone know how Slackware will address this? I'd hate to have to upgrade computer's for a 'jit' compiler feature that I don't use :)

Well, I can be wrong but there is no sign that QT5 will be shipped in next stable Slackware release, so you'll probably have to wait a bit to get an answer ;)

Meanwhile AlienBOB aka Eric Hameleers provides QT5 as a needed dependency of KDE 5 (Plasma 5.2.0) for testing purposes only, targeting Slackware-current, see this post blog .

As of v5.4.0, Eric hasn't made any mention in the Slackbuild to disable SSE2. Maybe it is to come, but since Eric is currently working on keeping up with KDE5 builds, his slackbuild and blog would be the things to check.

http://alien.slackbook.org/ktown/sou...ting/deps/qt5/

But as Didier mentioned, it isn't likely we'll see it in the next Slackware release, so there's plenty of time for Pat and Eric to figure out what to do with it.

EDIT: And there is never a public roadmap for Slackware available. There is probably an internal one that Pat uses, and he probably shares it with the core team, but good luck every getting a copy of it... if it does exist.

For as long as qt5 wants to run on ARM, qt5 will have to provide a flag to disable SSE2-specific code.

Other desktop environments are available, and there are P4 systems in every municipal dump from here to West Africa...

@Didier:

Good point. I had assumed that QT5 was going to be in/eventually in next version of Slackware since QT4 is reaching ending of life this year according to:

http://blog.qt.io/blog/2014/11/27/qt...-another-year/

I am not targeting old 32-bit CPU's with my testing packages. The whole SSE2 story is only relevant for 32-bit CPU's, and totally irrelevant for the ARM platform.

However, it is feasible to disable SSE2 completely. Also it seems that a hybrid approachs is possible where Qt 5 is compiled twice, first with SSE2 disabled and then again with SSE2 enabled, installing the SSE2-enabled QtCore, QtGui and QtDeclarative libraries in a ./sse2 sibdirectory.

See https://bugreports.qt.io/browse/QTBU...comment-250687

You really don't have a processor with sse2 support?

@moisespedro:

That is correct, about 8 computers without SSE2. Most of which are AMD processors which did not support SSE2 when the P4 came to market (and was substantially more expensive at the time). Believe it or not, an AMD 2500+ barton CAN run KDE4 surprisingly well with KDE's compositing effects running dual monitor. I mean it's surprisingly fast. The only thing that 'appears' slow, believe it or not, is waiting for the shutdown confirmation dialog box.

However I think it's worth mentioning to on-lookers, QT != KDE. There are many applications that I use that are independent of KDE. So I would like to have a QT package built for non-sse2 for my Slackware so that I can run those applications.

However, if this is not feasible as it might require Slackware to have two branches for 32bit, well then I certainly wouldn't want Mr. V and team to waste their time.

I'm just trying to plan accordingly, hee hee. These old machines run, and run well! I'm not a "hoarder", I'm an "archivist" :)

I may be wrong*, but Skype, GoogleEarth 7 and Steam require SSE2.
My desktop has a 32bit CPU without SSE2 and those programs don't run.
It seems that it's a matter of time to non-SSE2 CPUs become legacy.

*(I guess I may be wrong because it seems that 'SSE2 requirement' is
artificial or OS dependent. Skype, GoogleEarth7 and Steam can run in
windows XP in the same machine.)

I get it now :)

def jesting(self):
print("So I need to upgrade my computers so that my GNU - free software operating system can run "non-free" binary blobs ?")

jesting()

:) Yes, all those are closed source.
That's the reason why I think it's an artificial lock.

Just comparing, Linux kernel dropped 386 a couple years ago.
I think non-SSE2 machines deserve more time to live.

On the other hand, some OS already release only x86_64 version.