Created attachment 557656 [details] build logs for mupdf 1.13.0 on a ppc32 computer This is a critical bug because it blocks any first-time emerge of Gentoo (17) on any Big-Endian computer (this case: ppc32), ie. "emerge --ask --verbose --update --deep --newuse @world" will always fail on the profile "default/linux/powerpc/ppc32/17.0/desktop (stable)"! This bug is already listed here as "Bug 699395 - Build of lcms2art on big endian fails": "https://bugs.ghostscript.com/show_bug.cgi?id=699395" Please add the submitted patch of the above link to the building system, so that it can be built again on Big-Endian computers.
Please paste your emerge --info.
Created attachment 557672 [details] build logs for mupdf 1.14.0-r2 on a ppc32 computer
Created attachment 557678 [details, diff] patch to fix the problematic file "thirdparty/lcms2/src/cmsmd5.c" for both v1.13.0 and v1.14.0-r2 It is the patch file from "https://bugs.ghostscript.com/show_bug.cgi?id=699395" to fix the compilation errors.
I added the output for both the v1.13.0 and v1.14.0-r2 as archive files in the attachments: # emerge -pqv '=app-text/mupdf-1.13.0::gentoo' -- Build logs - mupdf 1.13.0.zip / Shell output.txt # emerge --info '=app-text/mupdf-1.13.0::gentoo' -- Build logs - mupdf 1.13.0.zip / Support output.txt # emerge -pqv '=app-text/mupdf-1.14.0-r2::gentoo' -- Build logs - mupdf 1.14.0-r2.zip / Shell output.txt # emerge --info '=app-text/mupdf-1.14.0-r2::gentoo' -- Build logs - mupdf 1.14.0-r2.zip / Support output.txt I tried to manually compile the problematic file "thirdparty/lcms2/src/cmsmd5.c" after the patch (3rd attachment) applied with success.
The patch seems straightforward enough and indeed it doesn't look like this code can possibly compile on big endian. It's strange that upstream let it sit in the bugzilla for so long. It's not unthinkable that big endian arches have more than this problem to worry about. Anyways, I happen to have a ppc64 machine, I'll work on this in the next few days.
Seems more like bug #668190 which was fixed upstream by http://git.ghostscript.com/?p=ghostpdl.git;h=90b8faa80a4746f7f1e0966d6c56a687d2f8d333
@ernsteiswuerfel 2018-12-13 18:20:33 UTC: Either the Gentoo package fetches an outdated sourcecode file or the sourcecode changes did not arrive in the main branch.
I can confirm the problem on ppc64 and also that the patch does the job. Now I'm really puzzled because zlogene (adding to CC) stabilized the ebuild in bug 671376. I really wonder how he managed to build it. I'm tempted to apply this patch directly to the stable ebuild since it prevents building, but if zlogene could build it, it means that a workaround is possible and that I could apply this patch in a revbump instead.
@Virgil Dupras: Were you successful in contacting the developer zlogene of the first fix (https://bugs.gentoo.org/show_bug.cgi?id=671376)? Maybe he has just tested against the Low-Endian architectures (x86, AMD64). The bug only shows on Big-Endian architectures (as PPC and PPC64 are).
He hasn't responded yet, I'm not sure why. But he has specifically stabilized ppc/ppc64 in https://bugs.gentoo.org/671376#c8
Still no answer from zlogene, including on IRC. I'll assume the worst, that is that he stabilized on ppc without even bothering to compile the package and I'll push my fix in a few minutes/hours.
mupdg used to build fine with USE=-lcms (0.12.0) but not it always uses bundled copy. Worst case we can drop ppc/ppc64 keywords and sort out depends.
Sergei: it's not needed the linked patch works fine. I just wanted to hear a word from zlogene, who stabilized mupdf 1.14 on ppc/ppc64 before I pushed a straight-to-stable commit. But seeing how I don't get an answer, I'll just push it.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a1b87a4250380f9fbc024147fa32eb679bd76848 commit a1b87a4250380f9fbc024147fa32eb679bd76848 Author: Virgil Dupras <vdupras@gentoo.org> AuthorDate: 2018-12-21 01:10:18 +0000 Commit: Virgil Dupras <vdupras@gentoo.org> CommitDate: 2018-12-21 01:10:18 +0000 app-text/mupdf: fix build errors on big endian arches Closes: https://bugs.gentoo.org/672998 Signed-off-by: Virgil Dupras <vdupras@gentoo.org> Package-Manager: Portage-2.3.51, Repoman-2.3.11 .../mupdf/files/mupdf-1.14-fix-big-endian.patch | 125 +++++++++++++++++++++ app-text/mupdf/mupdf-1.14.0-r2.ebuild | 2 + 2 files changed, 127 insertions(+)
