On 07/12/24 06:01, Vagrant Cascadian wrote:
On 2024-12-07, Gioele Barabucci wrote:
the libraries and executables of many cmake-based packages gain extra
zero bytes in their .dynstr ELF section when rebuilt. (This accounts for
about 15% of the failed rebuilds.)
From <https://reproduce.debian.net/api/v0/builds/105657/diffoscope>:
```
─ readelf --wide --decompress --hex-dump=.dynstr {}
@@ -1275,9 +1275,10 @@
0x00009388 00474c49 42435858 5f332e34 2e323100 .GLIBCXX_3.4.21.
0x00009398 43585841 42495f31 2e330047 4c494243 CXXABI_1.3.GLIBC
0x000093a8 58585f33 2e342e32 3000474c 49424358 XX_3.4.20.GLIBCX
0x000093b8 585f332e 34000000 00000000 00000000 X_3.4...........
0x000093c8 00000000 00000000 00000000 00000000 ................
0x000093d8 00000000 00000000 00000000 00000000 ................
0x000093e8 00000000 00000000 00000000 00000000 ................
- 0x000093f8 00000000 0000 ......
+ 0x000093f8 00000000 00000000 00000000 00000000 ................
+ 0x00009408 00000000 000000 .......
```
Oddly, sometimes the number of zero bytes added is odd.
My hunch is that this might be a side-effect of building in the wrong
build path, as mentioned in:
https://bugs.debian.org/1089087
That could indeed be the case.
The build paths for 105657 are
/build/reproducible-path/simbody-3.7+dfs
and
/build/reproducible-path/simbody-3.7+dfs/simbody-3.7+dfs
The second path is 16+1 characters longer and the .dynstr section
contains indeed 17 extra zeros.
Does GCC blank out (replace with zeroes) the build path?
Regards,
--
Gioele Barabucci
