Summary: | dev-python/wxpython-2.8.7.1 fails to build, dev-lang/python gentoo patch breaks distutils _compile interface | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Helmut Jarausch <jarausch> |
Component: | Current packages | Assignee: | Python Gentoo Team <python> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | aklhfex, andrey.prok, coldwind, cuciferus, gentoo, ikelos, john, koprut, pqGungnir, python, r.a, spamdummy, wxwidgets |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 230205 | ||
Attachments: |
patch for build wxPython-2.8.7.1 against python 2.5.2-r2
modified ebuild wxpython-2.8.7.1-cxxflags.patch |
Description
Helmut Jarausch
2008-04-25 06:09:29 UTC
Same error. Portage 2.1.5_rc6 (default-linux/amd64/2007.0, gcc-4.2.3, glibc-2.7-r2, 2.6.24-zen4-endar-v21 x86_64) ================================================================= System uname: 2.6.24-zen4-endar-v21 x86_64 AMD Turion(tm) 64 Mobile Technology MT-32 Timestamp of tree: Thu, 24 Apr 2008 19:16:01 +0000 app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.5 dev-lang/python: 2.4.4-r11 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.2.2 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.62 sys-devel/automake: 1.7.9-r1, 1.9.6-r2, 1.10.1 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.25-r1 ABI="amd64" ASFLAGS_x86="--32" AUTOCLEAN="yes" CAMERAS="canon ptp2" CBUILD="x86_64-pc-linux-gnu" CDEFINE_amd64="__x86_64__" CDEFINE_x86="__i386__" CFLAGS="-O2 -pipe -msse3 -march=athlon64" CFLAGS_x86="-m32 -L/emul/linux/x86/lib -L/emul/linux/x86/usr/lib" CHOST="x86_64-pc-linux-gnu" CHOST_amd64="x86_64-pc-linux-gnu" CHOST_x86="i686-pc-linux-gnu" looks like distutils breakage. python guys? in python-gentoo-patches-2.5.2-r2.tar.bz2 in file 18_all_distutils-cxxflags.patch this patch adds extra argument (lang=lang) to _compile function call. wxPython's build script defines custom _compile function without this extra argument. Ways to solve: remove _compile related patches from python-gentoo-patches or patch _ALL_ packages, who redefines _compile function. Created attachment 151295 [details, diff]
patch for build wxPython-2.8.7.1 against python 2.5.2-r2
This patch adds extra argument to redefined in wxPython build scripst _compile() function.
Created attachment 151296 [details]
modified ebuild
if distutil's patch in python 2.5.2 is persistent, then this ebuild solves the problem, else this is teporary solution.
*** Bug 219847 has been marked as a duplicate of this bug. *** Thanks for the patch guys! It now works(although the patch could be renamed to wxpython-2.8.7-build.patch for others to get minimum fuss) (In reply to comment #7) > Thanks for the patch guys! It now works(although the patch could be renamed to > wxpython-2.8.7-build.patch for others to get minimum fuss) > Works for me on amd64. Thanks! if this patch works it should be incorporated to portage just because it works doesn't mean it's the right fix. i need to know if the problem is with the distutils patch in python, or if the python team wants us to patch any package that uses custom _compile functions (i don't know how common this is, if at all). Created attachment 153063 [details, diff]
wxpython-2.8.7.1-cxxflags.patch
2.5.2-r3 and 2.4.4-r12 should work fine with wxpython. Attached is a patch for
wxpython-2.8.7.1 to respect CXXFLAGS. This is _not_ for wxpython itself but
for packages that uses wxpython's config.py to build.
Hiya guys, I just ran into this exact problem on python-2.6b3 and wxpython-2.8.8.1 (but then assumed it was an issue with the beta, rather than a gentoo patch). It's in 2.6b3 as 010_all_cflags.patch. It strikes me as a really bad idea to knowingly break an interface that people are recommended to subclass (such as the _compile interface). No other patch (at least in 2.6b3) changes function signatures, and probably with good reason. It might have been ok if there were a **kwargs entry in there originally, and it would just have been ignored, but this will break anyone that attempts to implement their own compiler. Moreover, at the moment it seems that the only place the lang variable is used is to choose the compiler to use, but it's identical whether lang is c or c++. Since we're only patching the UnixCompiler, would it not be possible to move the "lang = self.detect_language(sources)" inside the unixcompiler? If it's subclassed, then detect_language should still be a valid call, and would save us a lot of patching other _working_ packages... i'd just like to go on record as finding this whole thing kind of icky. if it's not going upstream then we should seriously question whether we should be doing it at all. I'd also like to note that 2.8.9.1 and 2.8.9.1-r1 also both fail for exactly the same reason (on python-2.6). Also, bug 240690 seems to be a duplicate and suggests that 2.8.8.1 fails (I don't know if it's been patched since I last tried it). Python guys, any chance you could make a decision one way or another, so we can figure out whether to remove the offending patch from python, or keep it and fix wxpython? It's a shame to have this hampering install for the past three versions of wxwidgets? *** Bug 240690 has been marked as a duplicate of this bug. *** *** Bug 243796 has been marked as a duplicate of this bug. *** Hello, First of all, sorry for the delay on this one. Here's the deal, the patch is really necessary for distutils to correctly use gentoo's cxxflags, so no icky things on this. The fact was that a proper patch was added to python-2.5.2-r3 and python-2.4.4-r12 that fixed the issue when UnixCCompiler was overridden and not properly reflected on this bug. That was the main cause why trying to get the error was difficult. However, the patch got lost with the version bump for python-2.6. dev-lang/python-2.6-r5 addresses this issue, re-adds lost patch to patchset and fixes the issue with packages overriding stuff from disutils' compilers. Best regards, PS: Closing this bug, please re-open as needed |