[Buildroot] [PATCH 2/2] package/mupdf: fix building with some toolchains

[Arnout Vandecappelle]

On 07/09/2021 14:09, Raphaël Mélotte wrote:
> With some toolchains (e.g. mips64el), partial linking fails in the
> following way:
> /tmp/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/mips64el-buildroot-linux-uclibc/8.4.0/../../../../mips64el-buildroot-linux-uclibc/bin/ld: build/release/libmupdf.a(Dingbats.cff.o): ABI is incompatible with that of the selected emulation
> /tmp/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/mips64el-buildroot-linux-uclibc/8.4.0/../../../../mips64el-buildroot-linux-uclibc/bin/ld: failed to merge target specific data of file build/release/libmupdf.a(Dingbats.cff.o)
> 
> Taking inspiration from commit
> 9eca4b9f84fe2535d8caee6eeb062ce33733bdf1, fix it by using GCC instead
> of LD for partial linking.
> 
> 'nostdlib' has to be added, or it will try to use GCC libraries for
> partial linking and fail with 'cannot find -lgcc_s'.
> 
> Note that on mips the build will now produce warnings similar to this
> one:
> /home/rme/Documents/buildroot/output/host/lib/gcc/mips64el-buildroot-linux-gnu/10.3.0/../../../../mips64el-buildroot-linux-gnu/bin/ld: build/release/libmupdf.a(NotoSansTaiTham-Regular.ttf.o): warning: linking abicalls files with non-abicalls files
> 
> During a runtime test on mips64el under qemu, mupdf-x11 was
> nonetheless able to display a sample PDF file correctly.
> 
> This fixes the following build failures (and many similar ones):
> http://autobuild.buildroot.net/results/156fe9ee5f6dccdc98990f6c5de5562383bc2b74/
> 
> Signed-off-by: Raphaël Mélotte <raphael.melotte at mind.be>
> ---
>   .../0001-use-gcc-instead-of-objcopy.patch     | 29 +++++++++++++++++++
>   1 file changed, 29 insertions(+)
>   create mode 100644 package/mupdf/0001-use-gcc-instead-of-objcopy.patch
> 
> diff --git a/package/mupdf/0001-use-gcc-instead-of-objcopy.patch b/package/mupdf/0001-use-gcc-instead-of-objcopy.patch
> new file mode 100644
> index 0000000000..9a8dacbcca
> --- /dev/null
> +++ b/package/mupdf/0001-use-gcc-instead-of-objcopy.patch
> @@ -0,0 +1,29 @@
> +From de27daedf8cb1d210b0b1facd87634c6aaaf1a74 Mon Sep 17 00:00:00 2001
> +From: =?UTF-8?q?Rapha=C3=ABl=20M=C3=A9lotte?= <raphael.melotte at mind.be>
> +Date: Thu, 2 Sep 2021 20:17:26 +0200
> +Subject: [PATCH] use gcc instead of objcopy
> +MIME-Version: 1.0
> +Content-Type: text/plain; charset=UTF-8
> +Content-Transfer-Encoding: 8bit
> +
> +Signed-off-by: Raphaël Mélotte <raphael.melotte at mind.be>

  What's the upstream status of this patch? We want to have a link to the 
upstream MR or patchwork or mailing list archive or whatever in the patch. Or, 
if that's not possible (e.g. upstream is dead), something like:

Upstream-Status: dead (no activity since 2003)


  Regards,
  Arnout

> +---
> + Makefile | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/Makefile b/Makefile
> +index b0fb617e2..0a8795e0e 100644
> +--- a/Makefile
> ++++ b/Makefile
> +@@ -64,7 +64,7 @@ endif
> + LINK_CMD = $(QUIET_LINK) $(MKTGTDIR) ; $(CC) $(LDFLAGS) -o $@ $^ $(LIBS)
> + TAGS_CMD = $(QUIET_TAGS) ctags -R --c-kinds=+p
> + WINDRES_CMD = $(QUIET_WINDRES) $(MKTGTDIR) ; $(WINDRES) $< $@
> +-OBJCOPY_CMD = $(QUIET_OBJCOPY) $(MKTGTDIR) ; $(LD) -r -b binary -z noexecstack -o $@ $<
> ++OBJCOPY_CMD = $(QUIET_OBJCOPY) $(MKTGTDIR) ; $(CC) -Wl,-r -Wl,-b -Wl,binary -Wl,-z -Wl,noexecstack -nostdlib -o $@ $<
> +
> + # --- Rules ---
> +
> +--
> +2.32.0
> +
>