This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: How to do patching?


 bjgnu@sunnorth.com.cn wrote:
> Hello all,
> 
> When patching a file, report following error message:
> Hunk #1 FAILED at 1184.
> Hunk #2 FAILED at 1238.
> Hunk #3 FAILED at 1840.
> Hunk #4 FAILED at 2000.
> Hunk #5 succeeded at 2409 with fuzz 2.
> 
> The operation flow is as follows:
> 1. copy diff text in maillist mail to my.patch

You should hunt down the original form of the patch. Patches in e-mail
sometimes get munged. Whitespace is significant in patches. In
particular, do not cut and paste patches from mailing list archives that
are hosted on the web.

You can use the -l or --ignore-whitespace options so that patch works
more "loosely", but the best thing is to just have the correct,
unmodified patch.

>    Note: I use emacs to edit my.patch.
>          My mail box is Lotus Notes.
>          I found there are many space in my.patch. 
> 2. execute "patch < my.patch", the above error message emit.
> 
> Which step is wrong or What is the problem?

That's impossible to diagnose without having an exact copy of your patch
and the files that it's being applied to.
You have to look at the patch hunks and the file together to see whether
the file has exactly matching context lines that patch can find.

If you are not applying the patch to the exact same base version of the
software against which it was produced, then you may get these errors
because the context lines in the patch do not match the text in the
source file. If that's the case, you have to "rediff" the patch. This
means: look at each hunk which did not apply, think about what that hunk
is trying to do, and then, if necessary, create the equivalent (though
obviously not identical) change in the file manually, using your
creativity and programming skill.  Sometimes the sources of conflict are
trivial. Someone reformatted the code with whitespace changes only, or
changed the name of an identifier, or fixed a spelling error in comment
text, whatever. Sometimes the conflicts are not trivial, and you have to
take some serious software engineering responsibility for doing the
rediffing. It may be best to go back to the original patch author and
ask if he or she has a rediffed verison of the patch against your
version of the code base.

You might want to learn how to use the "quilt" utility if you are doing
a lot of patching. It doesn't help with the patch resolution problems
themselves, but it helps to manage other aspects of the whole process.
Quilt makes rediffing easier because it keeps a pristine copy of the
patched files. You can force a patch with "quilt push -f", then manually
rediff the parts that didn't apply by editing the affected files. When
you are done just "quilt refresh" and the patch is replaced with a new
diff which applies cleanly to the original files.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]