Page MenuHomeFreeBSD

Add __ARM_ARCH_6KZ__ to devel/qt4-corelib
ClosedPublic

Authored by tcberner on Oct 22 2016, 7:41 AM.

Details

Reviewers
rakuco
mat
Group Reviewers
O5: Ports Framework(Owns No Changed Paths)
portmgr
Commits
rP442740: Fix qt4 ports on armv6.
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.

Diff Detail

Repository
rP FreeBSD ports repository
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 9636
Build 10078: arc lint + arc unit

Event Timeline

tcberner updated this revision to Diff 21611.Oct 22 2016, 7:41 AM
tcberner retitled this revision from to Add __ARM_ARCH_6KZ__ to devel/qt4-corelib.
tcberner updated this object.
tcberner edited the test plan for this revision. (Show Details)
tcberner added reviewers: rakuco, mat.
tcberner added a subscriber: adridg.
rakuco edited edge metadata.Oct 22 2016, 10:52 AM

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.

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 added a comment.Jun 1 2017, 3:19 PM
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.

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

tcberner updated this revision to Diff 29152.Jun 2 2017, 6:13 PM

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

tcberner updated this revision to Diff 29153.Jun 2 2017, 6:21 PM

... remove the webkit hunk

tcberner updated this revision to Diff 29154.Jun 2 2017, 6:23 PM

Bump revision in qt4-corelib

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

Mk/bsd.qt.mk
177

Can we name it armv6 please

tcberner updated this revision to Diff 29156.Jun 2 2017, 6:54 PM

Call the path -armv6

tcberner marked an inline comment as done.Jun 2 2017, 6:54 PM

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

@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

@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 updated this revision to Diff 29157.Jun 2 2017, 7:27 PM

Bump revisions in the mentioned ports.

All the qt4 ports build fine on armv6, thanks.

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

rakuco added a comment.Jun 4 2017, 8:03 PM

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?

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 accepted this revision.Jun 5 2017, 10:04 AM

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.

This revision was automatically updated to reflect the committed changes.