Source: libgc
Version: 7.6.4-0.4
Followup-For: Bug #872392
The config part of this patch has been accepted upstream. However
there is a new issue with the symbols file, which is probably
debian-specific.
The notation for the _Zna and _Znw symbols has been changed from:
(subst) _Zna{size_t}@BASE 1:7.2d
(subst) _Znw{size_t}@BASE 1:7.2d
to
(arch-bits=32)_Znaj@Base 1:7.6.4
(arch-bits=64)_Znam@Base 1:7.6.4
(arch-bits=32)_Znwj@Base 1:7.6.4
(arch-bits=64)_Znwm@Base 1:7.6.4
which seems sensible on the face of things, but only works if 32-bit ABIs
always use
'unsigned int' for size_t, and not 'unsigned long'.
c++filt says:
j is 'unsigned int'
m is 'unsigned long'
arm64ilp32 appears to use unsigned long for size_t (still 32-bits, so
nothing actually breaks) which means that the build fails during the
symbols check.
I've filed an issue upstream to check that I have correctly understood
what is going on here, but it seems that this symbol really does
depend on the type of size_t, not the bitsize of the architecture, so
should go back to the old notation.
https://github.com/ivmai/bdwgc/issues/241
Possibly arm64ilp32 is incorrect to use 'long unsigned int' for
size_t, and in fact that should be changed, but so far as I can tell
this is a valid implementation choice. It may be a pointless one that
just causes trouble though (libprelude exhibits the same symbol-naming
issue). I'm not sure how hard it would be to change at this point.
-- System Information:
Debian Release: 9.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-6-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
