Hunk #1 FAILED at 1. 这是什么意思？答案

【问题标题】：Hunk #1 FAILED at 1. What's that mean?Hunk #1 FAILED at 1. 这是什么意思？
【发布时间】：2012-12-26 07:09:15
【问题描述】：

我在运行make 时收到以下错误，我不知道这是什么意思，也不知道该怎么办。谁能照亮我或为我指明正确的方向？

(cd libdvdnav-git && patch -p1) < ../../contrib/src/dvdnav/dvdnav.patch
patching file Makefile.am
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file Makefile.am.rej
make: *** [dvdnav] Error 1

我正在尝试为 win32 交叉编译 VLC（使用 linux）。

【问题讨论】：

stackoverflow.com/questions/22845372/…

标签： makefile cross-compiling vlc

【解决方案1】：

这是由patch 生成的错误。如果您打开.patch 文件，您会看到它被组织成一堆片段，即所谓的“hunks”。每个块都标识了新旧版本中对应的代码段（按行号），这些代码段之间的差异以及它们之间的相似之处（“上下文”）。

如果大块的相似性与原始文件中的内容不匹配，大块可能会失败。当您看到此错误时，几乎总是因为您正在为您正在修补的代码的错误版本使用补丁。有几种方法可以解决这个问题：

获取已包含补丁的libdvdnav 的更新版本（最佳选择）。
为您正在修补的libdvdnav 版本获取.patch 文件。
手动修补。对于补丁中的每一个块，尝试在libdvdnav中找到对应的文件和行，并根据补丁中的说明进行更正。
采用更接近.patch 文件的任何版本的libdvdnav 版本（可能是个坏主意）。

【讨论】：

谢谢。因为我正在交叉编译并使用一个大脚本来获取库，所以我想我宁愿编辑补丁文件。你能告诉我@@符号那一行的含义吗？
您的补丁位于unified format。您可以忽略第二个@@ 之后的部分。在@@s之间，有两个术语：-l,s术语表示原始文件中hunk的偏移量（l是行数）和大小（s是行数），而+l,s 表示打补丁后文件中的偏移量和大小。当有多个大块头时，手动确定+l,s 部分可能会有点工作。
感谢您解释“hunk”一词并建议手动修补。

【解决方案2】：

在某些情况下，文件版本没有区别，而只是缩进、间距、行尾或行号。

要修补这些差异，可以使用以下两个参数：

--ignore-whitespace : 它忽略空白差异（缩进等）。

--fuzz 3 :“--fuzz X”选项将最大模糊因子设置为线条。此选项仅适用于上下文和统一差异；在寻找安装大块的地方时，它最多忽略 X 行。请注意，较大的模糊因子会增加制作错误补丁的几率。默认模糊因子为 2；没有必要将其设置为超过 diff 中的上下文行数，通常为 3。

别忘了给用户“--dry-run”：它会在不应用补丁的情况下尝试补丁。

例子：

patch --verbose --dry-run --ignore-whitespace --fuzz 3 < /path/to/patch.patch

【讨论】：

遇到了同样的问题。也许，只是管道而不是复制。
这对我来说是个问题。文件之间的制表符和空格混合
这解决了我编译libecwj的问题：patch --verbose --dry-run --ignore-whitespace --fuzz 3 -p1 < ../libecwj2-3.3-wcharfix.patch
Hunks 顺序也很重要。如果他们在文件中打补丁的代码出现在之前已经处理过的行之前（如果你刚刚给自己打了补丁，这不太可能发生，但如果你正在玩反向移植，那就不是那么荒谬了），不管任何模糊测试他们将失败。

【解决方案3】：

调试提示

将crlf添加到补丁文件的末尾，并测试它是否有效
尝试使用 --ignore-whitespace 命令，如下所示： markus@ubuntu:~$ patch -Np1 --ignore-whitespace -d software-1.0 < fix-bug.patch 见tutorial by markus

【讨论】：

【解决方案4】：

当我没有在相关 git 项目的顶级目录中应用补丁时，我收到了“hunks failed”消息。我在子目录中应用补丁（我创建它的地方）。

似乎可以从 git 项目中的子目录创建补丁，但不能应用。

【讨论】：

这不是真的。但是，您确实需要提供一个 -p 参数来说明在使用补丁时应该忽略路径的多少前导部分。 Patch 不知道存储库。 git am 是。

【解决方案5】：

按照here 的说明操作，它解决了我的问题。

你必须像下面这样运行命令； patch -p0 --dry-run

【讨论】：

【解决方案6】：

在我的情况下，IDEA 生成的补丁非常好，但是，我编辑并保存了补丁，将 CRLF 更改为 LF，然后补丁停止工作。奇怪的是，将其转换回 CRLF 不起作用。我在 VI 编辑器中注意到，即使设置为 DOS 格式，'^M' 也没有添加到行尾。这迫使我只在 VI 中进行更改，以便保留 EOL。

这可能适用于您，如果您在非 Windows 环境中对涵盖两个版本之间更改的补丁进行更改，这两个版本都来自 Windows 环境。您要小心编辑此类文件的方式。

顺便说一句，ignore-whitespace 没有帮助。

【讨论】：

【解决方案7】：

Hunk #1 在 1 时失败。 1 个大块中有 1 个失败 - 将拒绝保存到文件 Makefile.am.rej

当我通过补丁应用更改然后在 stackoverflow 上完全搜索时发现相同的错误，但我没有得到答案。

然后我搜索了小零件就像补丁错误背后的原因然后我发现

Hunk #n 在 nnn 失败。 n 个大块中的 n 个失败 - 将拒绝保存到文件 file.rej

这意味着不能将一个或多个称为大块的更改引入文件中。有时这可能是因为补丁通过电子邮件发送或复制到文件中，并且添加或删除了空格。尝试将 --ignore-whitespace 添加到命令行以解决此问题。

第 2 步

然后我搜索了不同的文件结尾，我发现有两种类型的格式系统LF，CF

然后我检查我的文件我使用什么格式

现在如果这个文件是在 *NIX 系统中创建的，它会显示

$ cat -A 文件你好$

你好$ 但如果这个文件是在 Windows 中制作的，它会显示

$ cat -A 文件你好^M$

你好^M

代表CR，$代表LF。请注意，Windows 没有使用 CRLF 保存最后一行

这是我从 stackoverflow 中找到的

然后我检查我的原始文件格式和 .patch/diff 我得到那个补丁文件同时具有 LF 和 Cf

然后我在将补丁应用到 windows 或 unix 格式之前转换这些文件

dos2unix 文件名.extension 或 unix2dos 文件名.extension

这会转换文件

然后应用补丁得到结果

命令提示符命令

创建文件 触摸文件名.txt

用于创建补丁/差异文件

diff -u originalfile.txt 编辑文件.txt > originalfile.diff 要么 diff -u originalfile.txt 编辑文件.txt > originalfile.patch

在应用更改检查文件格式之前

cat -A originalfile.txt
cat -A originalfile.diff

现在可以转换 doc2unix 或 unix2dos unix2dos originalfile.txt unix2dos originalfile.diff

应用更改 补丁 originalfile.txt

完成！！

希望对您有所帮助！

【讨论】：