0

I am trying to apply the following patch which repeatedly fails (hunk failure)

From 256ad97f332010ab6673052fe4e562e5ed2dadd2 Mon Sep 17 00:00:00 2001
From: Siu Kwan Lam <michael.lam.sk@gmail.com>
Date: Mon, 3 Feb 2020 14:44:54 -0600
Subject: [PATCH] Update LTO patch

LTO is the only shared library built by LLVM.  It breaks llvmlite
builds under Windows with the following message:

LINK : fatal error LNK1181: cannot open input file 'LTO-NOTFOUND.obj'
---
 tools/lto/CMakeLists.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/lto/CMakeLists.txt b/tools/lto/CMakeLists.txt
index b86e4ab..88e5ba0 100644
--- a/tools/lto/CMakeLists.txt
+++ b/tools/lto/CMakeLists.txt
@@ -20,7 +20,7 @@ set(SOURCES

 set(LLVM_EXPORTED_SYMBOL_FILE ${CMAKE_CURRENT_SOURCE_DIR}/lto.exports)

-add_llvm_library(LTO SHARED INSTALL_WITH_TOOLCHAIN ${SOURCES} DEPENDS intrinsics_gen)
+add_llvm_library(LTO INSTALL_WITH_TOOLCHAIN ${SOURCES} DEPENDS intrinsics_gen)

 install(FILES ${LLVM_MAIN_INCLUDE_DIR}/llvm-c/lto.h
   DESTINATION include/llvm-c
-- 
2.16.2

Below is the file that I'm trying to patch

set(LLVM_LINK_COMPONENTS
  AllTargetsAsmParsers
  AllTargetsCodeGens
  AllTargetsDescs
  AllTargetsDisassemblers
  AllTargetsInfos
  BitReader
  Core
  CodeGen
  LTO
  MC
  MCDisassembler
  Support
  Target
  )

set(SOURCES
  LTODisassembler.cpp
  lto.cpp
  )

set(LLVM_EXPORTED_SYMBOL_FILE ${CMAKE_CURRENT_SOURCE_DIR}/lto.exports)

add_llvm_library(LTO SHARED INSTALL_WITH_TOOLCHAIN ${SOURCES} DEPENDS
    intrinsics_gen)

install(FILES ${LLVM_MAIN_INCLUDE_DIR}/llvm-c/lto.h
  DESTINATION include/llvm-c
  COMPONENT LTO)

if (APPLE)
  set(LTO_VERSION ${LLVM_VERSION_MAJOR})
  if(LLVM_LTO_VERSION_OFFSET)
    math(EXPR LTO_VERSION "${LLVM_VERSION_MAJOR} + ${LLVM_LTO_VERSION_OFFSET}")
  endif()
  set_property(TARGET LTO APPEND_STRING PROPERTY
              LINK_FLAGS
              " -compatibility_version 1 -current_version 
${LTO_VERSION}.${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH}")
endif()

Notice that the patch shows

-add_llvm_library(LTO SHARED INSTALL_WITH_TOOLCHAIN ${SOURCES} DEPENDS intrinsics_gen)
+add_llvm_library(LTO INSTALL_WITH_TOOLCHAIN ${SOURCES} DEPENDS intrinsics_gen)

and the file to be patched has

add_llvm_library(LTO SHARED INSTALL_WITH_TOOLCHAIN ${SOURCES} DEPENDS
    intrinsics_gen)

Essentially, the file to be patched has line wrapping; the patch has one line

add_llvm_library(LTO SHARED INSTALL_WITH_TOOLCHAIN ${SOURCES} DEPENDS intrinsics_gen)

but is on two lines in the file I want to patch

add_llvm_library(LTO SHARED INSTALL_WITH_TOOLCHAIN ${SOURCES} DEPENDS
    intrinsics_gen)

Manually changing the file to be patched to

add_llvm_library(LTO SHARED INSTALL_WITH_TOOLCHAIN ${SOURCES} DEPENDS intrinsics_gen)

solves the problem and allows the patch to complete successfully. My question is following. Is there a way to apply patches when text wrapping like this occurs without going to each file manually and removing text wrap? I have played around with patch --ignore-whitespace and patch --fuzz=#lines, but I haven't been able to get around this problem with these flags.

HXSP1947
  • 1,311
  • 1
  • 16
  • 39
  • Did you create the patch? If so, I would run `diff` again with `diff -uNb oldFile newFile` to ignore changes in whitespace. (You can use `--label theLabel` once or twice to set the old/new label information at the top of the file). Then `patch -Np[0-9] -i file.patch` or just redirect the file to patch. I don't deal with DOS files, but you may want to investigate if DOS endings may cause issue. – David C. Rankin Nov 18 '21 at 03:54
  • No, I didn't create the patch. I have an entire directory of these patches that I want to apply, but it appears that every single one has this word wrap issue. – HXSP1947 Nov 18 '21 at 04:23
  • That makes things a bit more challenging. Even if you could get ahold of the original and the patched source, that would make things simpler as you could simply re-create a patch for the entire program in a single shot. The only "guess" I have is the DOS line ending issue. Search `CRLF` in [man 1 patch](https://man7.org/linux/man-pages/man1/patch.1.html) as well as looking at [How to fix "Hunk #1 FAILED at 1 (different line endings)" message?](https://unix.stackexchange.com/q/239364/197080) and [How do I get patch to ignore carriage returns?](https://stackoverflow.com/q/7754972/3422102) – David C. Rankin Nov 18 '21 at 04:36
  • The `-l` (`-(ell)`) option to `patch` looks promising. – David C. Rankin Nov 18 '21 at 04:36
  • do you mean --ignore-whitespace (which is also -l)? I've tried that previously and it didn't work. I'm not sure what (-(ell)) is. It very well could be a DOS/windows line ending issue since I would have thought --ignore-whitespace would have removed newlines. Looking at the links you provided the consensus seemed mostly to be to rebuild the patch, but I am not able to do that. – HXSP1947 Nov 18 '21 at 05:07
  • The `(ell)` was just to distinguish it from `(one)` that can be hard to tell apart in some fonts. – David C. Rankin Nov 18 '21 at 05:13
  • 1
    I think the issue is that the file you are attempting to patch has DOS line endings. When patch gets to a `'\r'` (as do most Linux tools) it returns to the begging of the line (carriage return -- typewriter days) which cases the hunk to fail. You may try a `dos2unix` conversion on the source before applying the patch (make backup copy first) and see if that helps. I've used `diff` and `patch` for decades, but never in a mixed environment -- so I don't have any direct experience with line-ending mismatches there. – David C. Rankin Nov 18 '21 at 05:19

0 Answers0