Created attachment 445186 [details] The file which the error message wanted to be included within the bug report When emerging the package on a machine using amd64 with the new x32 ABI, the prepare phase fails with the error message Failed Patch: 63_all_binutils-2.25.1-pt-pax-flags-20150727.patch ! * ( /var/tmp/portage/build/portage/sys-devel/binutils-2.25.1-r1/work/patch/63_all_binutils-2.25.1-pt-pax-flags-20150727.patch ) Include in your bugreport the contents of: * * /var/tmp/portage/build/portage/sys-devel/binutils-2.25.1-r1/temp/63_all_binutils-2.25.1-pt-pax-flags-20150727.patch.out * ERROR: sys-devel/binutils-2.25.1-r1::gentoo failed (prepare phase): * Failed Patch: 63_all_binutils-2.25.1-pt-pax-flags-20150727.patch! The *.patch.out file suggests there seems to be some pathname-related issue, because "patch" can't file some (all?) of its input files. Please examine the attached files for details. Hint: The x32 ABI is rather new and not very widely used. Perhaps some directories are named after the architecture, and the patch does not compensate for this?
Created attachment 445188 [details] Output of emerge --info
Created attachment 445190 [details] The USE flags for the package to be built
Created attachment 445192 [details] The directory structure after the failed application of the patch As this bug seems to be related to missing filenames or incorrectly named directories, I assumed it would be helpful to provide a recursive directory listing of the ebuild working directory. It has been generated with "find -ls".
Thanks for including the *.patch.out file. The "No file to patch" errors are expected: eutils epatch first tries patch -p0, then patch -p1, ... until something works. The most interesting part from *.patch.out is File ld/testsuite/ld-sparc/tlssunbin64.rd is read-only; trying to patch anyway patch: **** Can't create temporary file ld/testsuite/ld-sparc/tlssunbin64.rd.oichY60 : Too many open files Maybe the patch command has an x32 specific bug?
@felix: Oh, I didn't notice the "Too many open files" before, which you have quoted as part of the error message. I therefore conclude that this bug is not x32 specific as I assumed, but is rather a duplicate of bug 578878. Thanks for your quote, so we have one bug entry less to care about! Closing bug as duplicate.
*** This bug has been marked as a duplicate of bug 578878 ***
