Summary: | dev-python/PyQt4 fails to build with multilib-portage | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Thomas Sachau <tommy> |
Component: | New packages | Assignee: | Qt Bug Alias <qt> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | ftobin, python |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log for PyQt4-4.5.1
multilib header file with inclusion depending on current ABI |
Description
Thomas Sachau
2009-07-13 20:53:51 UTC
Created attachment 197840 [details]
build.log for PyQt4-4.5.1
Are you sure your qt4 headers are correctly installed? In particular, do you have /usr/include/qt4/QtGui/QTextObjectInterface ? Looks like bug 277985, no? (In reply to comment #3) > Looks like bug 277985, no? > No, that bug is only for crosscompile of distutils packages while this one is about normal compile of PyQt4 on amd64, no crosscompile. How does PyQt4 access the header files? Since i found out that it only happens with a special header file construction for multilib for qt-gui, it has do to something with the way, how PyQt4 does include the header. Created attachment 198221 [details]
multilib header file with inclusion depending on current ABI
The __i386__ and __x86_64__ macros, which are implicitly defined by gcc's preprocessor, are not defined by moc: thus both include directives are discarded and when moc later sees QTextObjectInterface it complains it cannot find its definition (because the header wasn't included). Adding -D__i386__ or -D__x86_64__ (depending on the current ABI) to moc's command line should fix the issue. Anyway, I don't know why QTextObject is treated as a multilib header, since I don't think it depends on the current ABI... Does multilib portage create a wrapper for every header file? (In reply to comment #6) > The __i386__ and __x86_64__ macros, which are implicitly defined by gcc's > preprocessor, are not defined by moc: thus both include directives are > discarded and when moc later sees QTextObjectInterface it complains it cannot > find its definition (because the header wasn't included). > > Adding -D__i386__ or -D__x86_64__ (depending on the current ABI) to moc's > command line should fix the issue. > > Anyway, I don't know why QTextObject is treated as a multilib header, since I > don't think it depends on the current ABI... Does multilib portage create a > wrapper for every header file? > multilib portage does save the headers for 32bit and 64bit phase and then does a diff between them and if they differ, it does install both headers and a wrapper for each header file of that package. Thomas I removed 4.5.1 from tree since there is 4.5.2 on tree already which is considered as a bug fix release. Did you try to build this one? I am adjusting the title accordingly (In reply to comment #7) > (In reply to comment #6) > > The __i386__ and __x86_64__ macros, which are implicitly defined by gcc's > > preprocessor, are not defined by moc: thus both include directives are > > discarded and when moc later sees QTextObjectInterface it complains it cannot > > find its definition (because the header wasn't included). > > > > Adding -D__i386__ or -D__x86_64__ (depending on the current ABI) to moc's > > command line should fix the issue. > > > > Anyway, I don't know why QTextObject is treated as a multilib header, since I > > don't think it depends on the current ABI... Does multilib portage create a > > wrapper for every header file? > > > > multilib portage does save the headers for 32bit and 64bit phase and then does > a diff between them and if they differ, it does install both headers and a > wrapper for each header file of that package. > So this means that if there exists at least one header file which is ABI-dependent, the whole set of headers (even ABI-independent ones) for that package gets wrapped by multilib portage? (In reply to comment #8) > Thomas I removed 4.5.1 from tree since there is 4.5.2 on tree already which is > considered as a bug fix release. Did you try to build this one? > > I am adjusting the title accordingly > same result with 4.5.2 (In reply to comment #9) > (In reply to comment #7) > > (In reply to comment #6) > > > The __i386__ and __x86_64__ macros, which are implicitly defined by gcc's > > > preprocessor, are not defined by moc: thus both include directives are > > > discarded and when moc later sees QTextObjectInterface it complains it cannot > > > find its definition (because the header wasn't included). > > > > > > Adding -D__i386__ or -D__x86_64__ (depending on the current ABI) to moc's > > > command line should fix the issue. > > > > > > Anyway, I don't know why QTextObject is treated as a multilib header, since I > > > don't think it depends on the current ABI... Does multilib portage create a > > > wrapper for every header file? > > > > > > > multilib portage does save the headers for 32bit and 64bit phase and then does > > a diff between them and if they differ, it does install both headers and a > > wrapper for each header file of that package. > > > > So this means that if there exists at least one header file which is > ABI-dependent, the whole set of headers (even ABI-independent ones) for that > package gets wrapped by multilib portage? > That is, how it currently works, yes. Another problem: qt version checks like #if QT_VERSION (< or >=) 0xfoobar ...some stuff... #endif seem to be broken. (btw, can someone change the summary to reflect that all these issues are caused by headers wrapping in multilib setups?) I believe that *every* Qt4-based app using moc is currently broken on multilib setups. moc has very limited preprocessing capabilities, as noted in the docs, and the header wrapping performed by multilib portage is deliberately violating those restrictions. I see 3 possible solutions: (1) add -D$(get_abi_CDEFINE) to every moc invocation: this can be easy or very hard depending on the build system; eqmake4 should be changed to pass DEFINES+=$(get_abi_CDEFINE) to qmake, which will fix most qmake-based packages, but won't fix PyQt4 for example. (IMHO this solution sucks because it's not general) (2) report the issue upstream and ask them to change moc to automatically define some platform macros like gcc does. (probably the best solution, but it could take a lot of time before upstream fixes it) (3) declare this bug INVALID and design a better solution for multilib headers handling. (note: a better solution may not exist :P) I just noticed the following in PMS section 12.4: "Each phase function must be called at most once during the build process for any given package." It seems to me that multilib portage is violating this requirement. Please correct me if I'm wrong. (In reply to comment #13) > I just noticed the following in PMS section 12.4: > > "Each phase function must be called at most once during the build process for > any given package." > > It seems to me that multilib portage is violating this requirement. Please > correct me if I'm wrong. > This part may have to be modified for multilib support. Basicly, multilib-portage does call each phase once, but for every ABI. If you want to enforce this part on multilib-aware package managers, you would have to introduce something different like another var, which behaves similar to the current SLOT. Thanks for the explanation. I was just pointing out that the current multilib implementation can be very intrusive wrt. ebuilds and eclasses, because some of them rely upon that assumption, and fail when it isn't respected. Are there any recent updates on this bug? (In reply to comment #16) > Are there any recent updates on this bug? > The specific bug itself still exists, but does not show up with the current implementation. But there are other bugs related to multilib-portage like not respecting the current environment. Probably best to do a IRC session for debugging and fixing this mess. IMHO this bug cannot be fixed with the current multilib implementation. The only thing to be fixed here is the handling of multilib headers, and that one is a multilib portage bug. I'm afraid I was probably wrong in comment #12, solutions (1) and (2) wouldn't really solve anything :( Thomas, did you make any progress with this? (In reply to comment #19) > Thomas, did you make any progress with this? > From what i can see, this is no bug in multilib-portage itself, but related to the custom buildsystem of qt-related packages. Since the headers PyQt4 currently checks are the same for amd64 and x86, the bug does not show up, but still exists there, if noone did add a workaround/fix in the background. Thomas, seeing that you proposed multilib portage for EAPI 5, it might be better to resurrect this bug and try to find a solution. First of all, I suppose the situation hasn't changed since 2 years ago, right? As i wrote before: currently, this issue is hidden since the header files, that are used by PyQt4, dont differ between amd64 and x86, so those header files dont get wrapped. Beside that, there is not much one can do from package manager side for custom build systems (and no, adding workarounds for issues in every custom build system found in the wild is no fix, it just hides the issues). PyQt4 includes a new build system, which according to upstream[1], will in the future support cross-compilation. [1]: http://www.riverbankcomputing.co.uk/news/pyqt-4101 (In reply to Michael Palimaka (kensington) from comment #23) > PyQt4 includes a new build system, which according to upstream[1], will in > the future support cross-compilation. > > [1]: http://www.riverbankcomputing.co.uk/news/pyqt-4101 >=PyQt4-4.11.2-r1 has been switched to using configure-ng.py (although I'm not sure how this is related to the original bug report) We're not going to support multilib-portage, sorry. Closing as WONTFIX (and given the moc limitations mentioned above, might even be CANTFIX). The current approach using multilib-minimal.eclass seems to yield better results (we're only wrapping two header files for now). |