Bug 704442

Summary:	Partial linking fails on mips
Product:	MuPDF	Reporter:	raphael.melotte
Component:	mupdf	Assignee:	MuPDF bugs <mupdf-bugs>
Status:	RESOLVED FIXED
Severity:	normal	CC:	fontaine.fabrice
Priority:	P4
Version:	master
Hardware:	Other
OS:	Linux
Customer:		Word Size:	---
Attachments:	0001-Use-CC-instead-of-LD-for-OBJCOPY.patch Patch to compile hexdump.exe for host

Description raphael.melotte 2021-09-26 16:57:43 UTC

Created attachment 21584 [details]
0001-Use-CC-instead-of-LD-for-OBJCOPY.patch

Cross-compiling for mips targets using buildroot 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)


The attached patch fixes it by using CC for partial linking, instead of calling LD directly.

Fixes:
- http://autobuild.buildroot.net/results/156fe9ee5f6dccdc98990f6c5de5562383bc2b74

Comment 1 raphael.melotte 2021-09-26 18:06:36 UTC

Note that with this patch, on mips the build will now produce warnings similar to this
one:
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-abica
lls files

During a runtime test on mips64el under qemu, mupdf-x11 was
nonetheless able to display a sample PDF file correctly.

Comment 2 Tor Andersson 2021-09-28 14:27:45 UTC

With troublesome build tools I recommend compiling without OBJCOPY. Have you tried compiling with:

$ make HAVE_OBJCOPY=no

Comment 3 raphael.melotte 2021-10-20 08:50:27 UTC

Thanks for the suggestion!

If I compile with "make HAVE_OBJCOPY=no" it has no effect (I think it's overridden by the "($(OS),Linux)" branch in the Makerules).

If I force HAVE_OBJCOPY to "no", then it compiles "scripts/hexdump.c" to "build/release/scripts/hexdump.exe".

Later in the build it tries to execute hexdump.exe.

When cross-compiling, hexdump.exe is compiled for the target so executing it on the host doesn't work:
/bin/sh: 1: build/release/scripts/hexdump.exe: Exec format error

To be able to use this approach when cross-compiling we would have to change it so that hexdump.c is compiled for the host and not for the target.

Comment 4 fontaine.fabrice 2021-11-15 17:32:32 UTC

Created attachment 21888 [details]
Patch to compile hexdump.exe for host

Comment 5 fontaine.fabrice 2021-11-15 17:32:55 UTC

As reported by Raphael, hexdump.exe must be compiled for the host, not the target. You'll find attached a patch.

Comment 6 Tor Andersson 2022-03-15 13:20:07 UTC

The following patch sequence removes the need for a host compiler when cross
compiling:

commit 1dec1ad54b5005189586715c49072696ae035af1
Author: Tor Andersson <tor.andersson@artifex.com>
Date:   Wed Dec 1 13:35:48 2021 +0100

    Implement scripts/hexdump as a bash script.
    
    Simplify cross compilation by removing the need for a host compiler in
    the 'make generate' step.

commit ab72b00ef5ca2476ab768037c18793545540a28d
Author: Tor Andersson <tor.andersson@artifex.com>
Date:   Mon Dec 6 17:02:48 2021 +0100

    Fix hexdump script for files with many zeroes.
    
    Pass -v to od so it doesn't mark duplicate rows with *.

commit 115a027c8fc6d065bcd52a4b6d14efa15abb8c64
Author: Tor Andersson <tor.andersson@artifex.com>
Date:   Wed Dec 8 12:23:58 2021 +0100

    Fix hexdump.sh script to work with MacOS's slightly different od output.