Summary: | x11-libs/qt-dbus-4.7.2 - ../../include/QtCore/../../src/corelib/arch/qatomic_generic.h:197: error: invalid conversion from ‘const void*’ to ‘void*’ | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jeroen Roovers (RETIRED) <jer> |
Component: | [OLD] Library | Assignee: | Qt Bug Alias <qt> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | hppa |
Priority: | Normal | Keywords: | PATCH |
Version: | unspecified | ||
Hardware: | HPPA | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 354033, 390963 | ||
Attachments: |
x11-libs:qt-dbus-4.7.2:20110516-201256.log [hppa,fail]
QT parisc-linux patch |
Description
Jeroen Roovers (RETIRED)
![]() Found a bit of code putting HPPA in the generic corner, while traditionally anything hppa is normally called parisc. Testing with this patch now (rebuilding all of =x11-libs/qt-*-4.7.2): Index: qt4-build.eclass =================================================================== RCS file: /var/cvsroot/gentoo-x86/eclass/qt4-build.eclass,v retrieving revision 1.90 diff -u -B -r1.90 qt4-build.eclass --- qt4-build.eclass 10 Mar 2011 23:45:51 -0000 1.90 +++ qt4-build.eclass 18 May 2011 00:56:29 -0000 @@ -460,7 +460,8 @@ x86-macos) myconf+=" -arch x86" ;; x86|x86-*) myconf+=" -arch i386" ;; alpha|arm|ia64|mips|s390|sparc) myconf+=" -arch $(tc-arch)" ;; - hppa|sh) myconf+=" -arch generic" ;; + hppa) myconf+=" -arch parisc" ;; + sh) myconf+=" -arch generic" ;; *) die "$(tc-arch) is unsupported by this eclass. Please file a bug." ;; esac (In reply to comment #1) > Found a bit of code putting HPPA in the generic corner, while traditionally > anything hppa is normally called parisc. Testing with this patch now > (rebuilding all of =x11-libs/qt-*-4.7.2): No, that wasn't it. The assembly code appears to be for the HP-UX assembler. :-\ Created attachment 290413 [details, diff]
QT parisc-linux patch
Along with changing the architecture in qt4-build.eclass, the pach qt-parisc-linux.diff
The tested patch needs to be applied to qt-* (provide they all come from the same source file).
Compiling works fine but I haven't had the opportunity to test the changes yet.
That patch would need to go into qt-core too, since that installs the actual .h file. Testing right now... It requires a change to qt4-build.eclass as well, since HPPA wouldn't be using "-arch generic" any longer. One would suspect that SH is also affected by this "generic" bug, then. Index: qt4-build.eclass =================================================================== RCS file: /var/cvsroot/gentoo-x86/eclass/qt4-build.eclass,v retrieving revision 1.96 diff -u -B -r1.96 qt4-build.eclass --- qt4-build.eclass 30 Oct 2011 14:21:14 -0000 1.96 +++ qt4-build.eclass 2 Nov 2011 16:52:58 -0000 @@ -494,7 +494,8 @@ x86-macos) myconf+=" -arch x86" ;; x86|x86-*) myconf+=" -arch i386" ;; alpha|arm|ia64|mips|s390|sparc) myconf+=" -arch $(tc-arch)" ;; - hppa|sh) myconf+=" -arch generic" ;; + sh) myconf+=" -arch generic" ;; + hppa) myconf+=" -arch parisc" ;; *) die "$(tc-arch) is unsupported by this eclass. Please file a bug." ;; esac Qt team: Could you advise how to best include this patch in the tree? It needs to be added to the following packages: x11-libs/qt-core x11-libs/qt-dbus x11-libs/qt-gui x11-libs/qt-opengl x11-libs/qt-script x11-libs/qt-xmlpatterns and is known to work with 4.7.2 - later versions have not been tested. I don't follow... isn't that patch against a header file installed by qt-core? If so, patching qt-core should be enough (plus qt4-build.eclass of course). As far as I can tell, all x11-libs/qt-* that unpack the corelib directory actually include the headers found there. This isn't going anywhere and it's holding up stabilisation for HPPA, which means holding up deprecation of older x11-libs/qt*. We have a patch, it works, now it needs to be incorporated properly in your ebuilds. Why this patch is not in the upstream code? (In reply to comment #10) > Why this patch is not in the upstream code? That's a good question. I suppose someone in qt@ serves as upstream contact. (In reply to comment #11) > (In reply to comment #10) > > Why this patch is not in the upstream code? > > That's a good question. I suppose someone in qt@ serves as upstream contact. Not quite. I can report it upstream but I wonder why no other disto hit this bug (In reply to comment #12) > Not quite. I can report it upstream Well, please do. Is this still reproducible in 4.8? If so please adjust the title and I will open a bug report upstream (In reply to comment #14) > Is this still reproducible in 4.8? I suppose so, since the code is identical... https://bugreports.qt-project.org/browse/QTBUG-17962 Seems like it has already been reported but upstream does not care at all. Jer, would it be possible to try this patch? https://bugreports.qt-project.org/secure/attachment/20844/qt-dbus-const.diff If it works for you, then we don't need the qt4-build eclass patch that Guy attached Just to be clear, you must not use Guy's qt4-build.eclass patch when using the patch I attached in my previous comment. (In reply to comment #16) > https://bugreports.qt-project.org/browse/QTBUG-17962 > > Seems like it has already been reported but upstream does not care at all. > Jer, would it be possible to try this patch? You could very well try it yourself by simply setting `-arch generic'. After all, the bug is in the C code, not anything platform specific. > https://bugreports.qt-project.org/secure/attachment/20844/qt-dbus-const.diff I'll give it a go. > If it works for you, then we don't need the qt4-build eclass patch that Guy > attached Guy's patch works fine. What's wrong with it except that upstream is too retarded to pick it up? (In reply to comment #18) > (In reply to comment #16) > > https://bugreports.qt-project.org/browse/QTBUG-17962 > > > > Seems like it has already been reported but upstream does not care at all. > > Jer, would it be possible to try this patch? > > You could very well try it yourself by simply setting `-arch generic'. After > all, the bug is in the C code, not anything platform specific. I could but I don't want to because my hardware resources are limited > > > https://bugreports.qt-project.org/secure/attachment/20844/qt-dbus-const.diff > > I'll give it a go. > > > If it works for you, then we don't need the qt4-build eclass patch that Guy > > attached > > Guy's patch works fine. What's wrong with it except that upstream is too > retarded to pick it up? The thing is that we can apply the patch I told you immediately because we know upstream will never accept it. But if we decide to go with Gury's patch then we need to push it upstream and wait for upstream to reply on that (In reply to comment #18) > (In reply to comment #16) > > https://bugreports.qt-project.org/browse/QTBUG-17962 > > > > Seems like it has already been reported but upstream does not care at all. Then they ought to drop all the Linux/HPPA support files Bitrot set in years ago and every attempt to salvage it is declined. > > Jer, would it be possible to try this patch? > I'll give it a go. It's fine. Looks like both qt-core and qt-dbus need the patch. This looks interesting: https://bugreports.qt-project.org/browse/QTBUG-22479 (In reply to comment #21) > This looks interesting: https://bugreports.qt-project.org/browse/QTBUG-22479 Just another example. Upstream needs to get rid of code they refuse to support. Now can we please get the generic const patch integrated so we can finally fix bug #354033 (and related bugs)? Finally fixed in qt-dbus-4.7.4 and 4.8.1. Apologies for the huge delay. |