With USE="-python", file-4.21-r1 merges correctly. With USE="python" the process fails with: running build running build_ext building 'magic' extension creating build creating build/temp.irix64-6.5-2.5 cc -OPT:Olimit=0 -c99 -O2 -n32 -mips4 -r14000 -float_const -use_readonly_const -TARG:isa=mips4:platform=ip35:processor=r14000 -TENV:zeroinit_in_bss=ON -OPT:fast_io=ON:Olimit=8192:reorg_common=ON:swp=ON -LNO:auto_dist=ON:fusion_peeling_limit=8:gather_scatter=2 -woff 1174,1183,1185,1552,3968,3970 -D_GNU_SOURCE -I/opt/portage/usr/include -I./ -I../ -I../src -I/usr/include/ -I/opt/portage/usr/include/python2.5 -c py_magic.c -o build/temp.irix64-6.5-2.5/py_magic.o creating build/lib.irix64-6.5-2.5 ld -shared -all -Wl,-v,-s,-x,-n32,-mips4,-rdata_shared,-allow_jump_at_eop,-rpath,/opt/portage/usr/lib:/opt/portage/lib -L/opt/portage/usr/lib -L/opt/portage/lib -c99 -O2 -n32 -mips4 -r14000 -float_const -use_readonly_const -TARG:isa=mips4:platform=ip35:processor=r14000 -TENV:zeroinit_in_bss=ON -OPT:fast_io=ON:Olimit=8192:reorg_common=ON:swp=ON -LNO:auto_dist=ON:fusion_peeling_limit=8:gather_scatter=2 -woff 1174,1183,1185,1552,3968,3970 -D_GNU_SOURCE -I/opt/portage/usr/include build/temp.irix64-6.5-2.5/py_magic.o -L./ -L../ -L../src/.libs -L/usr/lib/ -lmagic -lpython2.5 -o build/lib.irix64-6.5-2.5/magic.so (null): WARNING 1 : Unknown option: Wl,-v,-s,-x,-n32,-mips4,-rdata_shared,-allow_jump_at_eop,-rpath,/opt/portage/usr/lib:/opt/portage/lib (ignored). (null): WARNING 1 : Unknown option: c99 (ignored). (null): WARNING 1 : Unknown option: O2 (ignored). (null): WARNING 1 : Unknown option: r14000 (ignored). (null): WARNING 1 : Unknown option: float_const (ignored). (null): WARNING 1 : Unknown option: use_readonly_const (ignored). (null): WARNING 1 : Unknown option: TARG:isa=mips4:platform=ip35:processor=r14000 (ignored). (null): WARNING 1 : Unknown option: D_GNU_SOURCE (ignored). (null): WARNING 1 : Unknown option: I/opt/portage/usr/include (ignored). ld32: FATAL 9 : I/O error (-lpython2.5): No such file or directory error: command 'ld' failed with exit status 32 * * ERROR: sys-apps/file-4.21-r1 failed. * Call stack: * ebuild.sh, line 46: Called src_compile * environment, line 2942: Called distutils_src_compile * environment, line 845: Called die * The specific snippet of code: * ${python} setup.py build "$@" || diefunc "$FUNCNAME" "$LINENO" "$?" "compilation failed" * The die message: * compilation failed ... so the easiest issue to address here is that file includes '-L/usr/lib/' which is obviously not prefix-safe. Also, ld is being invoked with CFLAGS, but unfortunately if LDFLAGS are specifically set directly (rather than being passed to $CC via the "-Wl" option) then configure fails because the $CC correctness test uses "$CC $CFLAGS $LDFLAGS". Since no other package breaks in this way (and even file only breaks if compiled with USE="python") then I'm calling this a bug in file. Finally - and this probably isn't a bug in file(?) - despite having python (2.5) installed and working (in that portage works, and other python-* packages install correctly) there is no libpython.so on my system. There is a $EPREFIX/usr/lib/python2.5/config/libpython2.5.a however... I'll file this last as a seperate bug against python.
(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)
