tools/qregularexpression.cpp: In member function 'QRegularExpressionMatchPrivate* QRegularExpressionPrivate::doMatch(const QString&, int, QRegularExpression::MatchType, QRegularExpression::MatchOptions, bool, const QRegularExpressionMatchPrivate*) const': tools/qregularexpression.cpp:1241:73: error: passing 'const QAtomicPointer<pcre16_extra>' as 'this' argument of 'T* QBasicAtomicPointer<T>::loadAcquire() [with T = pcre16_extra]' discards qualifiers [-fpermissive] const pcre16_extra * const currentStudyData = studyData.loadAcquire(); The failure implies -fpermissive *may* help, but I'm not sure of the wisdom of trying that.
This is trying to build qt5-qtbase-5.1.1-2 on either epel-6/ppc64 or f20/ppc
http://qt-project.org/doc/qt-5.0/qtdoc/platform-notes-mac.html Says at least that Powerpc/Mac builds are not supported.
(In reply to Rex Dieter from comment #2) > http://qt-project.org/doc/qt-5.0/qtdoc/platform-notes-mac.html > > Says at least that Powerpc/Mac builds are not supported. I guess this is more OSX issue than ppc one, also can "we don't care". FWIW qt5-qtbase now builds on s390/s390x after fixing one big endian related issue. Don't understand yet why it doesn't fail in the same way on ppc ...
On the surface, this would appear to be an arch-specific issue with qatomic operations, which may or may not be also endian related.
Did we exclude arch this to just work around. Want us to peek at this?
(In reply to baude from comment #5) > Did we exclude arch this to just work around. Want us to peek at this? Brent, yes, please take a look.
Created attachment 812643 [details] Set loadAcquire() as const This patch fixes the build on ppc64. I haven't tested it on ppc32 or x86 though. This patch is rather trivial, it only adds a 'const' modifier to loadAcquire(). I may be missing something here though. It may have a deeper impact due to qatomic semantics. I'd appreciate if someone with better understanding of qatomic semantics and implementation could review it.
patch confirmed good (well, stuff builds at least), scratch builds: epel-6 : http://koji.fedoraproject.org/koji/taskinfo?taskID=6066254 f20 ppc-koji : http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=1458064 Removed all the qt5- ExcludeArch: ppc stuff and -docs generation (from 5.2.0-alpha rawhide) so that we can bootstrap ppc
I think we can close this now
For the history of this issue, loadAcquire was made const in February 2012: https://qt.gitorious.org/qt/qtbase/commit/3f1a4be30263a676b7e188bf6cfa809c7788c87f but they forgot to apply this change also to qoldbasicatomic.h which is still used by the PPC port.
Rex, we're going to need this built on primary for f20 in order to take it in on Power. Can you please do an f20 build? Thanks!
OK, re-opening, I can backport this to f20 5.1.1 builds
Hrm, was thinking there would be some good benefit to rebasing f20 to qt5 5.2.0-alpha now/asap, to gain this fix as well as: 1. dropped qt5-qtjsbackend v8 stuff that was ExclusiveArch: %ix86, x86_64, arm 2. support for system harfbuzz 3. better/complete documentation the 5.2.0-beta is due real soon too. Any comment or objections ?
qt5-qtbase-5.1.1-6.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/qt5-qtbase-5.1.1-6.fc20
Package qt5-qtbase-5.1.1-6.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing qt5-qtbase-5.1.1-6.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-19398/qt5-qtbase-5.1.1-6.fc20 then log in and leave karma (feedback).
nominating for f20 beta freeze exception
Proposed as a Freeze Exception for 20-beta by Fedora user rdieter using the blocker tracking app because: unblocks builds for dependant packages (including poppler->libreoffice) for ppc
Discussed this in 2013-10-21 Blocker Review Meeting [1]. It is not clear why we would want to take 1005482 through the freeze; we will request a clearer explanation and discuss this again at the next meeting. [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-10-21/
Let me clarify. I was told by ppc secondary arch folks that they need stuff to go stable before it builds in their koji instance. Making them wait a week or 2 for this means a number of significant packages cannot be built. This is a small/safe ppc-only change, little to no risk elsewhere. With fix in hand, I thought this could be a no-brainer?
+1 from fedora for power - we need updates to go stable on primary in order to be able to ship them in fedora for power. (Typically blockers from us become freeze exceptions for primary if they're not intrusive or destabilizing.)
Discussed at 2013-10-23 freeze exception review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-10-23/f20-blocker-review.2013-10-23-16.00.log.txt . Accepted as a freeze exception issue, as this is apparently roadblocking PPC composes: showstoppers for secondary arches are typically accepted as freeze exception issues. Danger to primary arches is minimal.
qt5-qtbase-5.1.1-6.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.