The memory hdr_id is disabled on SPARC because it relies on memory
accesses that aren't sufficiently aligned for SPARC - IIRC, it's aligned
to sizeof(void *) which doesn't work fully on SPARC systems, but I could
be wrong (I'm not looking at the sources right now).
If the failure is due to it being enable on x86 (and most other
platforms) and not on SPARC, either Debian could opt to disable the
hdr_id stuff for all platforms, or I can look into making it work
correctly on SPARC.
I have to confess, even though I added it to Ghostcript, I was at the
the time, and still am, unconvinced of its utility....
Chris
On 14/02/16 11:25, John Paul Adrian Glaubitz wrote:
Source: ghostscript
Version: 9.16~dfsg-2.1
Severity: normal
User: debian-sparc@lists.debian.org
Usertags: sparc64
Hello!
ghostscript currently fails to build from source on sparc64 due to a mismatched
symbols file:
dpkg-gensymbols: warning: debian/libgs9/DEBIAN/symbols doesn't match completely
debian/libgs9.symbols
--- debian/libgs9.symbols (libgs9_9.16~dfsg-2.1_sparc64)
+++ dpkg-gensymbolsIeNygU 2016-02-04 01:22:29.643520921 +0000
@@ -3332,7 +3332,7 @@
gxht_thresh_planes@Base 9.05~
hc_put_code_proc@Base 8.61.dfsg.1
hc_put_last_bits_proc@Base 8.61.dfsg.1
- hdr_id@Base 9.10~dfsg
+#MISSING: 9.16~dfsg-2.1# hdr_id@Base 9.10~dfsg
height@Base 8.61.dfsg.1
ht_order_procs_table@Base 8.61.dfsg.1
#MISSING: 9.00~dfsg-1# iWrite2@Base 8.61.dfsg.1
@@ -4004,6 +4004,7 @@
pixel_image_params@Base 8.61.dfsg.1
pixmap_high_level_pattern@Base 9.10~dfsg
plane_device_init@Base 8.61.dfsg.1
+ png_push_fill_buffer@Base 9.16~dfsg-2.1
pop_estack@Base 8.61.dfsg.1
pprintd1@Base 8.61.dfsg.1
pprintd2@Base 8.61.dfsg.1
dh_makeshlibs: failing due to earlier errors
The simple and obvious fix would be to mark the "hdr_id" symbol on sparc64 as
missing which I have already done for the package in the 'unreleased' suite,
(arch!=sparc64) hdr_id@Base 9.10~dfsg
which works fine. However, I think it would be better to figure out first why
this particular symbol is missing on sparc64 and whether this poses any problem.
So far, the patched version seems to work without issues and we therefore
might just go ahead and patch the symbols file as suggested, but it would
be still be good if someone could have a deeper look at this. Maybe it's
any of the (transitive) build dependencies of ghostscript which need to be
rebuilt?
Cheers,
Adrian