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)