Add __ARM_ARCH_6KZ__ to devel/qt4-corelib

[tcberner]

Summary

Due to a misspelling in GCC [1] (probably) the check for the ARMv6KZ platform
used ARM_ARCH_6ZK instead of ARM_ARCH_6KZ.

Append the correct spellings to the checks for ARM_ARCH_6ZK.

Patch slightly modified from PR 210027 [2]

[1] https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01679.html
[2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210027

Test Plan

I have no armv6 platfrom to properly test.

[rakuco]

FWIW, the gcc patch did get committed: https://github.com/gcc-mirror/gcc/commit/ab2874bae238c48204394aac7b235f78cc107f8d

With that said, are you sure patching qt4-corelib is the right option? It doesn't install the wtf/Platform.h, so to me it looks like qt4-script and qt4-webkit won't be fixed at all.

[adridg]

The important part of the patch is the change to qatomic; the wtf part might make more sense in the qt4-webkit and -script ports (simply duplicating the patch to the affected ports? it's all the same distfile, after all)

[rakuco]

In D8322#227899, @groot_kde.org wrote:

The important part of the patch is the change to qatomic

This part looks fine to me. I think you need to bump PORTREVISION though, as I guess qt4-corelib currently builds fine on ARM, but the ports depending on it need to pick up the new header version.

the wtf part might make more sense in the qt4-webkit and -script ports (simply duplicating the patch to the affected ports? it's all the same distfile, after all)

I think it only makes sense in those ports: these headers are not installed, so you need to patch them during qt4-webkit/qt4-script's build for the changes to be picked up.

[tcberner]

I'll try to look at all the arm-prs this weekend, and update the diff then.

[tcberner]

Add extrapatch to qt4/files and include it for all qt4 ports.

[tcberner]

... remove the webkit hunk

[tcberner]

Bump revision in qt4-corelib

[tcberner]

Actually, probably only the bump to qt4-corelib is required, as the other stuff did not build anyways.

[mikael]

Mk/bsd.qt.mk

177 ↗

(On Diff #29154)

Can we name it armv6 please

[tcberner]

Call the path -armv6

[tcberner]

@mikael.urankar_gmail.com did any of the qt4-* ports apart from qt4-corelib actually build? Or did they all fail during build?

[mikael]

In D8322#228514, @tcberner wrote:

@mikael.urankar_gmail.com did any of the qt4-* ports apart from qt4-corelib actually build? Or did they all fail during build?

A lot of qt4 ports build successfully but have their runtime broken, the exhaustive list is here https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210027#c8

[tcberner]

In D8322#228515, @mikael.urankar_gmail.com wrote:

In D8322#228514, @tcberner wrote:

@mikael.urankar_gmail.com did any of the qt4-* ports apart from qt4-corelib actually build? Or did they all fail during build?

A lot of qt4 ports build successfully but have their runtime broken, the exhaustive list is here https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210027#c8

Ok, then I probably should bump all these.

[tcberner]

Bump revisions in the mentioned ports.

[mikael]

All the qt4 ports build fine on armv6, thanks.

[tcberner]

OK, then if @rakuco and Co is fine with the bumps I will commit it tonight.

[rakuco]

In D8322#228515, @mikael.urankar_gmail.com wrote:

A lot of qt4 ports build successfully but have their runtime broken, the exhaustive list is here https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210027#c8

What does "broken runtime" mean? Do they just crash when those instructions are reached instead of failing to build due to type mismatches?

[mikael]

In D8322#228815, @rakuco wrote:

In D8322#228515, @mikael.urankar_gmail.com wrote:

A lot of qt4 ports build successfully but have their runtime broken, the exhaustive list is here https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210027#c8

What does "broken runtime" mean? Do they just crash when those instructions are reached instead of failing to build due to type mismatches?

They build fine but the binary (or library) contains invalid atomic ops (the linux one: ffff0fc0) and they crash. Here is an example of qdbusxml2cpp crashing (R15=ffff0fc0):
http://beefy8.nyi.freebsd.org/data/head-armv6-default/p441125_s318432/logs/errors/qtkeychain-qt4-0.7.0.log

There is no type mismatch.

[rakuco]

In D8322#228824, @mikael.urankar_gmail.com wrote:

They build fine but the binary (or library) contains invalid atomic ops (the linux one: ffff0fc0) and they crash. Here is an example of qdbusxml2cpp crashing (R15=ffff0fc0):
http://beefy8.nyi.freebsd.org/data/head-armv6-default/p441125_s318432/logs/errors/qtkeychain-qt4-0.7.0.log

Thanks for the clarification. @tcberner, please go ahead.