Thanks for the pointers. But I think I'm not able to fix it even if
I tried to diagnose the debug information.

ATM I asked several people and it is likely that the dwz error
stems from toolchain support problem. Now the build log on non-release
archivectures are also available, and it seems that nearly all these
non-release architectures (kind of) suffer from similar prblem.

Temporarily overriding dh_dwz to noop it is an eligible solution to me.
Another solution could be simply downgrading dh compat back to 11.

On Sat, Jan 12, 2019 at 04:10:02PM +0000, Rebecca N. Palmer wrote:
> I suspect this is caused by bumping debhelper compat (while often a good
> idea, this is intentionally *not* risk-free, which is why it requires
> explicit action), but I haven't actually tried fixing it by reverting this.
> codesearch finds that message in dwz:
> https://sources.debian.org/src/dwz/0.12-3/dwz.c/?hl=1016#L1016
> dwz was added to the standard dh sequence in compat 12:
> https://sources.debian.org/src/debhelper/12/debhelper.pod/#L860
> As it seems to relate to debug information, it might be a good idea to test
> whether that works:
> # apt-get install libsleef3-dbgsym
> $ gdb --args <executable (not script) that uses libsleef3>
> (gdb) break <somewhere in the sleef source, in file.c:123 format>
> (gdb) run
> [wait for "hit Breakpoint", or if it's a program that spends most of its
> time in sleef, press Ctrl+C]
> (gdb) bt full
> [should show source line numbers and parameter values, i.e. like #909379 not
> #914021]

Reply via email to