Summary: | dev-lang/python doesn't build libpython2.5.so on IRIX | ||
---|---|---|---|
Product: | Gentoo/Alt | Reporter: | Stuart Shelton <srcshelton> |
Component: | Prefix Support | Assignee: | Gentoo non-Linux Team <alt> |
Status: | RESOLVED FIXED | ||
Severity: | minor | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | IRIX | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Stuart Shelton
2008-02-07 12:15:55 UTC
(In reply to comment #0) > With USE="-python", file-4.21-r1 merges correctly. With USE="python" the > process fails with: <snip> Not unconditionally true...Compiles fine here on x86-linux & sparc-solaris with USE=python. file-4.23 confirmed to work w/ USE=python on: "x86-linux amd64-linux ia64-linux ia64-hpux sparc-solaris x86-solaris" file-4.21-r1 confirmed to work w/ USE=python on: "x86-linux sparc-solaris" (I suspect more but I don't want to downgrade and upgrade again on every arch =) @Stuart, 4.21 is old, when is the last time you have synced? I have had 4.23 installed since the beginning of Jan '08. Do you have any other ARCHs? It appears this bug is only on your system from my point of view ;) (Adding myself to CC to help if I can) I think this is either distutils trying to be smart, and python being built wrongly, as it should have built a libpython2.5.so. For Darwin this isn't automatically built either, so we had to patch there, maybe for IRIX we need to do the same. Ah, interesting - it sounds as if IRIX also needs a variant of the Darwin fix, then. I've since upgraded to a later version of python, and there's still no libpython anywhere on the system, which is (obviously) breaking any builds which utilise the 'python' USE flag, if enabled. Renaming this bug to match the actual problem. Python has an annoyance factor which is pretty high. /me can be no more help here. Removing CC I'm now very confused... I'm not sure how would be best to integrate this into the ebuild, but I was finally able to get libpython25.so installed by manually compiling the package using 'ebuild' then entering python's ${S} directory and performing the following operatons: mkdir libpython cd libpython ar -x ../libpython2.5.a $CC $CFLAGS $LDFLAGS -shared -o ../libpython2.5.so *.o ... and with this, I noticed that the ebuild automagically installed libpython2.5.a into $EPREFIX/usr/lib and symlinked libpython.2.5.so to it (so it wasn't even using the .so file I'd just generated). I then rebuilt exactly the same ebuild but without manually creating libpython2.5.so, and this time neither libpython2.5.a nor the libpython2.5.so symlink were created! Presumably a patch almost identical to python-2.5.1-darwin-libpython2.5.patch could be used to address this? s/python$/tmp/g The install process breaks if there's anything unexpected matching libpython* in the ${S} directory, so any temporary directory shouldn't be named 'libpython'. if I'm not mistaken we build a libpython on IRIX now too. Yup - looks as if this now works just fine, for python2.6 at least. (There are still various parts of python - such as the ctypes and libffi modules - which don't build, but none of these seem to affect core functionality) |