Bug#967005: dh_ocaml: produces binaries with corrupt DWARF information (causes many FTBFS)
Le 03/08/2020 à 11:49, Lucas Nussbaum a écrit :
> During an archive rebuild in unstable/amd64, I ran into many similar
> failures, affecting only ocaml packages (see the list in Affects). An
> example is yojson:
>
>> make[1]: Leaving directory '/tmp/yojson-1.7.0'
>> dh_dwz
>> dwz -- debian/libyojson-ocaml-dev/usr/bin/ydump
>> dwz: debian/libyojson-ocaml-dev/usr/bin/ydump: DWARF version 0 unhandled
>> dh_dwz: error: dwz -- debian/libyojson-ocaml-dev/usr/bin/ydump returned exit code 1
>> make: *** [debian/rules:19: binary] Error 1
>> dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
>
> I don't understand what happens here.
>
> The produced binary seems to be a valid ELF binary:
>> # file debian/libyojson-ocaml-dev/usr/bin/ydump
>> debian/libyojson-ocaml-dev/usr/bin/ydump: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=eef3c12415e20f123d1c5432747bea6b33c015cd, for GNU/Linux 3.2.0, with debug_info, not stripped
>
> But its debugging info seems to be corrupt, as also shown by dwarfdump:
>> # dwarfdump debian/libyojson-ocaml-dev/usr/bin/ydump
>>
>> .debug_info
>>
>> dwarfdump ERROR: Failure reading CU header or DIE, corrupt DWARF: DW_DLE_VERSION_STAMP_ERROR (48). Attempting to continue.
>> dwarfdump ERROR: attempting to print .debug_info: DW_DLE_VERSION_STAMP_ERROR (48) (48)
>> attempting to continue.
>>
>> .debug_str
>> name at offset 0x00000000, length 11 is 'std_exit.ml'
>> name at offset 0x0000000c, length 8 is './stdlib'
>> name at offset 0x00000015, length 11 is 'GNU AS 2.35'
>> name at offset 0x00000021, length 12 is 'bin/ydump.ml'
>> [...]
>
> Note: I filed this against dh-ocaml, but another package might be at
> fault here.
binutils dropped support for the DWARF version produced by ocamlopt.
This is #965372.
I don't see what can be done from OCaml side, except waiting for
ocamlopt to produce modern DWARF. Meanwhile, empty dh_dwz overrides are
being added.
Cheers,
--
Stéphane
Reply to: