Summary: | x11-libs/qt-core-4.5.0 fails to build on ppc64 (32-bit ul); attempts to build with -m64 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Ian Leonard <antonlacon> |
Component: | [OLD] Library | Assignee: | Qt Bug Alias <qt> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ppc64 |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | PPC64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 266201 |
Description
Ian Leonard
2009-03-06 05:03:03 UTC
thx for the report. Assigning to maintainers and CC'ing ppc64 team for additional advice if needed. will look into it; usually a naughty assumption based on uname or something Here is a lengthy update. First, a little background for those not familiar with PowerPC. With Gentoo, we offer three flavors: 1. ppc - 32bit kernel, 32bit userland, arch is ppc 2. ppc64 32UL - 64 bit kernel, 32bit userland, arch is ppc 3. ppc64 64UL - 64 bit kernel, 64bit userland, arch is ppc64 The problem for this bug is option 2. Qt-4.5 (and earlier) uses the various results of uname -foo to determine what architecture, OS, etc it is working on. It then makes assumptions based on that for compilation. The most important assumption for powerpc is that it assumes if it finds a 64bit (ppc64) kernel, the userland should also be 64bit. Same for ppc being 32bit. The latter is a safe assumption. The former is th crux of the problem for scenario 2. The previous (qt-4.4) configure scripts seem to be able to deal with this. I'm not sure why--the configure scripts differ a fair amount between 4.4 and 4.5. There are numerous ways to deal with this. Here is one which I have tested. Consider this patch for the ebuild: --- qt-core-4.5.0.ebuild 2009-03-17 10:15:21.000000000 -0500 +++ qt-core-4.5.0.ebuild.orig 2009-03-17 10:10:44.000000000 -0500 @@ -139,9 +139,6 @@ myconf="${myconf} -nomake docs" fi - # Bug 261412 Qt configure detects archs by uname - [[ ${ARCH} == "ppc" ]] && myconf="${myconf} -platform linux-g++-32" - cp -f "${FILESDIR}"/moc.pro "${S}"/src/tools/moc/ cp -f "${FILESDIR}"/rcc.pro "${S}"/src/tools/rcc/ cp -f "${FILESDIR}"/uic.pro "${S}"/src/tools/uic/ Basically, we determine if the arch is ppc, then pass the appropriate platform. This gcc tupple makes the configure script get the right compiler. This is tested and works fine. I assume no objection from the ppc32 proper folks would exist. If there is, we can test for both arch being ppc and the kernel arch being ppc64 to make the test more selective. There is one negative side effect to this (and it was present in qt-4.4), though as I said earlier the configuration script dealt with it. Even with the patched ebuild, the output for the qt build will produce something like: This is the Qt/X11 Open Source Edition. Determining system architecture... (Linux:2.6.25-gentoo-r7:ppc64) 64-bit PowerPC (powerpc) 'powerpc' is supported System architecture: 'powerpc' So, in addition to patching the ebuild, something like this might be really nice: --- qt-x11-opensource-src-4.5.0.orig/configure 2009-02-25 15:09:13.000000000 -0600 +++ qt-x11-opensource-src-4.5.0/configure 2009-03-17 10:08:57.000000000 -0500 @@ -2480,7 +2480,9 @@ CFG_HOST_ARCH=powerpc ;; *:*:ppc64) - if [ "$OPT_VERBOSE" = "yes" ]; then + if [ "$PLATFORM" = "linux-g++-32" ]; then + echo " 32-bit userland with 64-bit PowerPC (powerpc) kernel" + else echo " 64-bit PowerPC (powerpc)" fi CFG_HOST_ARCH=powerpc Ok, a couple of other thoughts. If we have a good relationship with qt upstream, we could consider asking them to advise on this. They do similar foo as I posted above in their configure script for amd. It would seem they could make this change for powerpc as well. Lastly, if we choose to go this route, we need to change all the qt-*-4.5 ebuilds unless there is some qt-4 eclass trickery we can do. Brent, that was an excellent analysis. However patching all the ebuilds is not that handy. One way ( but I am not that happy about this ) to fix this is by creating a tarball with patches for ppc64,mirror it , and use it when ${ARCH}=ppc is detected. This patching should be done directly on eclass and not on every single ebuild. Since you have a good relationship with qt upstream, it would be nice to provide your patches upstream just to let them know what this is all about. If those stuff are fixed upstream they will help us a lot :) Let me know if you contact them Markos, I don't have any relationship with QT upstream. I'm sorry if I inferred that I did. When you say won't patch the ebuilds, do you mean you would not add: # Bug 261412 Qt configure detects archs by uname [[ ${ARCH} == "ppc" ]] && myconf="${myconf} -platform linux-g++-32" to the qt ebuilds? or are you referring to the second suggestion which is an actual patch to make things *appear* better? Problem remains in 4.5.1. Adding block to #266201 I applied that patch proposed by Brent on qt4-build eclass. Could you please resync your tree and try to recompile qt-4.5 solution worked.... |