emerging gcc-3.3.1-r5 fails when trying to apply the patch mentioned in the topic here's 02_all_gcc33-ice-hack.patch.bz2-24454.out: missing header for unified diff at line 292 of patch can't find file to patch at input line 292 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |--- gcc/diagnostic.c.jj 2003-06-03 08:45:21.000000000 -0400 |+++ gcc/diagnostic.c 2003-06-05 12:20:06.000000000 -0400 -------------------------- No file to patch. Skipping patch. 2 out of 2 hunks ignored missing header for unified diff at line 292 of patch_gcc33-ice-hack.patch.bz2-24454.out can't find file to patch at input line 292 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |--- gcc/diagnostic.c.jj 2003-06-03 08:45:21.000000000 -0400 |+++ gcc/diagnostic.c 2003-06-05 12:20:06.000000000 -0400 -------------------------- No file to patch. Skipping patch. 2 out of 2 hunks ignored Reproducible: Always Steps to Reproduce: 1. emerge -u gcc 2. 3.
*** Bug 31082 has been marked as a duplicate of this bug. ***
*** Bug 31088 has been marked as a duplicate of this bug. ***
Well, I can get it to compile by altering the ebuild slightly... however I'm new to all this, so I'm not sure if I'm actively breaking something desirable here :-) I'll just give ya a diff -u: if anyone is desperate right now to compile gcc-3.3.1-rc5 and get that beautiful empty emerge -uDp world list, this will do it, but I'm not responsible for things stuffing up later... Really lame hack follows.. :) --- /usr/portage/sys-devel/gcc/gcc-3.3.1-r5.ebuild 2003-10-14 05:03:43.000000000 +0000 +++ /usr/portage/sys-devel/gcc/gcc-3.3.1-r5.ebuild2 2003-10-14 06:08:47.358479608 +0000 @@ -212,9 +212,10 @@ if [ -n "${PP_VER}" ] && [ "${ARCH}" != "hppa" ] then # ProPolice Stack Smashing protection + mv -f ${WORKDIR}/patch/* ${WORKDIR}/patch/exclude/ EPATCH_OPTS="${EPATCH_OPTS} ${WORKDIR}/protector.dif" \ epatch /tmp/gcc331-pp-fixup.patch - epatch ${WORKDIR}/protector.dif + #epatch ${WORKDIR}/protector.dif cp ${WORKDIR}/protector.c ${WORKDIR}/${P}/gcc/ || die "protector.c not found" cp ${WORKDIR}/protector.h ${WORKDIR}/${P}/gcc/ || die "protector.h not found" version_patch ${FILESDIR}/3.3.1/gcc331-gentoo-branding.patch \
*** Bug 31094 has been marked as a duplicate of this bug. ***
as I said in a duplicate, this type of failure in the gc ebuilds has been on-and-off since 3.1 appeared over a year ago. I'd like to know why this keeps cropping up. Perhaps those of us who have changed the default locations of their overlay, distfiles, and portage tree are the only ones who 'hit the wall' on this? Can we drop a comment in the ebuild that says "try hard not to patch like this... as it causes trouble downstream..."?
*** Bug 31111 has been marked as a duplicate of this bug. ***
ebuild fails due to an attempt to apply the patch set twice: root@misaki neko # emerge -u gcc Calculating dependencies ...done! >>> emerge (1 of 1) sys-devel/gcc-3.3.1-r5 to / >>> md5 src_uri ;-) gcc-3.3.1.tar.bz2 >>> md5 src_uri ;-) gcc-3.3.1-patches-1.5.tar.bz2 >>> md5 src_uri ;-) gcc-3.3.1-branch-update-20030927.patch.bz2 >>> md5 src_uri ;-) protector-3.3-4.tar.gz >>> md5 src_uri ;-) gcc-3.3.1-manpages.tar.bz2 >>> Unpacking source... >>> Unpacking gcc-3.3.1.tar.bz2 to /var/tmp/portage/gcc-3.3.1-r5/work >>> Unpacking gcc-3.3.1-patches-1.5.tar.bz2 to /var/tmp/portage/gcc-3.3.1-r5/work >>> Unpacking protector-3.3-4.tar.gz to /var/tmp/portage/gcc-3.3.1-r5/work * Working directory: /var/tmp/portage/gcc-3.3.1-r5/work/gcc-3.3.1... * Applying libtool-test.patch... * Applying libtool-tmp.patch... * Applying libtool-sed.patch... * Applying libtool-portage.patch... * Applying gcc-3.3.1-branch-update-20030927.patch.bz2... [ ok ] * Applying various patches (bugfixes/updates)... * 02_all_gcc33-ice-hack.patch.bz2... [ ok ] * 12_all_gcc331-unsharing_lhs.patch.bz2... [ ok ] * 15_all_gcc33-multi-os-directory.patch.bz2... [ ok ] * 16_all_gcc33-c99-double-inline.patch.bz2... [ ok ] * 17_all_gcc33-c99-numbers.patch.bz2... [ ok ] * 23_all_gcc33-c++-decl2.patch.bz2... [ ok ] * 25_all_gcc33-libstdc++-pic.patch.bz2... [ ok ] * 26_all_gcc33-m68k-const.patch.bz2... [ ok ] * 27_all_gcc33-m68k-java-build.patch.bz2... [ ok ] * 28_all_gcc33-m68k-loop.patch.bz2... [ ok ] * 29_all_gcc33-m68k-subreg.patch.bz2... [ ok ] * 40_all_gcc331-c++-modify-cond.patch.bz2... [ ok ] * 41_all_gcc331-sched-ebb-cselib.patch.bz2... [ ok ] * 50_all_gcc33-coreutils-compat.patch.bz2... [ ok ] * Done with patching * Applying various patches (bugfixes/updates)... * 02_all_gcc33-ice-hack.patch.bz2... * Failed Patch: 02_all_gcc33-ice-hack.patch.bz2! * * Include in your bugreport the contents of: * * /var/tmp/portage/gcc-3.3.1-r5/temp/02_all_gcc33-ice-hack.patch.bz2-1097.out !!! ERROR: sys-devel/gcc-3.3.1-r5 failed. !!! Function epatch, Line 322, Exitcode 0 !!! Failed Patch: 02_all_gcc33-ice-hack.patch.bz2!
*** Bug 31104 has been marked as a duplicate of this bug. ***
*** Bug 31116 has been marked as a duplicate of this bug. ***
On ferret's hack, the following will generate a nasty error:- mv -f ${WORKDIR}/patch/* ${WORKDIR}/patch/exclude/ mv: cannot move `/var/tmp/portage/gcc-3.3.1-r5/work/patch/exclude' to a subdirectory of itself, `/var/tmp/p ortage/gcc-3.3.1-r5/work/patch/exclude/exclude' So, here is another lame hack:- # ProPolice Stack Smashing protection mkdir -p ${WORKDIR}/applied mv -f ${WORKDIR}/patch/* ${WORKDIR}/applied/ EPATCH_OPTS="${EPATCH_OPTS} ${WORKDIR}/protector.dif" \ epatch /tmp/gcc331-pp-fixup.patch #epatch ${WORKDIR}/protector.dif cp ${WORKDIR}/protector.c ${WORKDIR}/${P}/gcc/ || die "protector.c not found" By the way, at that point, it should be safe to purge the contents of ${WORKDIR}/patch/ , since all the relavent patches therein have already been applied. Also, I am not sure about commenting "epatch ${WORKDIR}/protector.dif" Comments anyone?
same happened to me.
<quote> Perhaps those of us who have changed the default locations of their overlay, distfiles, and portage tree are the only ones who 'hit the wall' on this? </quote> I have two machines that I've hit the wall on, and all of my locations are default. Ones a p3, the other a p4, pretty conservative flags are set. Seems it's effecting most everyone. joe
Broken for me as well in the exact same manner.
the mising file /tmp/gcc331-pp-fixup.patch is the cause, perhaps a bug in extra_functions: no files found => ${WORKDIR}/patch as default but if you rem the line epatch /tmp/gcc331-pp-fixup.patch, protector.dif don't work an new "#include input.h" in gcc/expr.c broke the patch
*** Bug 31137 has been marked as a duplicate of this bug. ***
Why was this assigned to gcc-porting and not Azarah? Reassigning...
*** Bug 31136 has been marked as a duplicate of this bug. ***
What if you changed: -- EPATCH_OPTS="${EPATCH_OPTS} ${WORKDIR}/protector.dif" \ epatch /tmp/gcc331-pp-fixup.patch -- to: -- EPATCH_OPTS="${WORKDIR}/protector.dif" \ epatch /tmp/gcc331-pp-fixup.patch -- Note that we do not care about the old EPATCH_OPTS. It might contain a stale variable from somewhere .. ?
Martin I just tried what you recommended, same old problem. It's as Patrick stated "the mising file /tmp/gcc331-pp-fixup.patch" I monitored the tmp dir while gcc was emerging, no such file. I was able to emerge, however, by skiping the last patch, ie the pp patch.
Ok, I was on crack there or something, sorry guys! Should be fixed in CVS now. For those that are using rsync, I am attaching the patch.
Created attachment 19235 [details, diff] /tmp/gcc331-pp-fixup.patch Just cp to /tmp/gcc331-pp-fixup.patch =)
Feel free to close when rsync catches up.
*** Bug 31147 has been marked as a duplicate of this bug. ***
in portage now
*** Bug 31173 has been marked as a duplicate of this bug. ***
*** Bug 32184 has been marked as a duplicate of this bug. ***
