Created attachment 496334 [details] build log Repeated relocation errors occur causing build to fail. Problem appears to be the use of -fpic rather than -fPIC on Ultrasparc IIIi processor. Was able to get a successful compile by specifying EXTRA_EMAKE="XCFLAGS=-fPIC" in /etc/portage/package.env
Still there.
Can someone with access to a sparc machine submit a patch? This problem is blocking the resolution of security bugs and, if this bug report is correct, mupdf on sparc has now been broken for quite a while. I'd tend to unkeyword it.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3fdb6a4636768465bba3df9da04b84705db2d9e3 commit 3fdb6a4636768465bba3df9da04b84705db2d9e3 Author: Virgil Dupras <vdupras@gentoo.org> AuthorDate: 2018-10-08 20:01:57 +0000 Commit: Virgil Dupras <vdupras@gentoo.org> CommitDate: 2018-10-08 20:01:57 +0000 app-text/mupdf: drop ~sparc keyword It seems that mupdf is durably broken on sparc. Closes: https://bugs.gentoo.org/631970 Closes: https://bugs.gentoo.org/658438 Signed-off-by: Virgil Dupras <vdupras@gentoo.org> Package-Manager: Portage-2.3.50, Repoman-2.3.11 app-text/mupdf/mupdf-1.13.0-r1.ebuild | 4 ++-- app-text/mupdf/mupdf-1.13.0.ebuild | 4 ++-- app-text/mupdf/mupdf-1.14.0.ebuild | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a5eb4ff9187e9d634ca34a197e72d084151ebf21 commit a5eb4ff9187e9d634ca34a197e72d084151ebf21 Author: Eli Schwartz <eschwartz93@gmail.com> AuthorDate: 2024-02-05 14:22:13 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-02-05 14:29:11 +0000 profiles/arch/sparc: update and expand cups + pdf stable-mask Followup to commit ccc97ae9448678fa5971a4a41f89e8778550ceed. Still trying to stabilize new group of cups packages after shuffling and splitting up components. Originally nattka complained about hppa, now after fixing that, it is complaining about sparc too. The problem is the same problem -- unstable mupdf -- but this time tied to a different bug. Bug: https://bugs.gentoo.org/923811 Bug: https://bugs.gentoo.org/631970 Signed-off-by: Eli Schwartz <eschwartz93@gmail.com> Signed-off-by: Sam James <sam@gentoo.org> profiles/arch/sparc/package.use.mask | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a3d9d727aebb5f958446ffbc2a994508aef21119 commit a3d9d727aebb5f958446ffbc2a994508aef21119 Author: Eli Schwartz <eschwartz93@gmail.com> AuthorDate: 2024-02-05 15:05:45 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-02-05 15:34:44 +0000 profiles/arch/sparc: fix totally bogus mupdf-based cups mask In bug 631970, mupdf dropped its sparc keyword for nonsense reasons. Due to an ebuild bug, it was wrong everywhere and actually failed to build on sparc. Despite diagnosis in the original report, it was left unfixed for years after dropping ~sparc: > Can someone with access to a sparc machine submit a patch? [...] if > this bug report is correct, mupdf on sparc has now been broken for quite > a while. I'd tend to unkeyword it. Fast forward to 2021, and commit 41543c0badfcd7ba9ee39386a3f4a8c8675135c0 which ninja-fixed this inside another commit. Now mupdf builds sanely. Fast forward again to 2023, and bug 761550, where it was keyworded for ~sparc. This odd mask is outdated and incorrect in a few different ways! The status today is much more simple: the feature is expected to work on ~sparc, but no one has requested stabilizing mupdf for sparc. Hence, cups *can* be built with USE=pdf, as long as you don't mind running unstable keywords. Move the mask from use, to use.stable, and correct the false information. Bug: https://bugs.gentoo.org/631970 Signed-off-by: Eli Schwartz <eschwartz93@gmail.com> Signed-off-by: Sam James <sam@gentoo.org> profiles/arch/sparc/package.use.mask | 7 ------- profiles/arch/sparc/package.use.stable.mask | 7 +++++++ 2 files changed, 7 insertions(+), 7 deletions(-)
