symbol sizes changing

[Vagrant Cascadian]

On 2020-12-28, Nick Black wrote:
> Hey there Reproducible Builds team!
>
> I'd like to make my package "notcurses" reproducible. First off,
> I love the interface at
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/notcurses.html,
> the clearest output I've seen yet from diffoscope(?).
>
> All my differences seem to be due to small changes in dynamic
> symbol sizes. See for example data.tar.xz's 'readelf --wide
> --dynamic {}' output:
>
> 18  ·0x000000000000000a·(STRSZ)··············3446·(bytes)
> 18  ·0x000000000000000a·(STRSZ)··············3450·(bytes)
>
> What might be causing these symbol sizes to change?

Since it seems to historically consistently build reproducibly in
bullseye, my first guess would be that it is build path related; build
paths are not tested in our infrastructure on bullseye.

In unstable and experimental we do test build paths, but also pass
DEB_BUILD_OPTIONS=reproducible=+fixfilepath, which passes the
-ffile-prefix-map=BUILDPATH=. argument, stripping the build path, but
sometimes leaves traces; the length of the build path is different
(e.g. /1/2/3 vs. /1/2/3/4), so it leaves a different amount of
padded/empty space.


Does notcurses use __FILE__ macros anywhere (either directly in the
source code, or indirectly via some other build system)? Something along
those lines would be needed to completely fix the issue.


> I also have some _NT_GNU_BUILD_ID changes, but I think I can
> handle those myself. Thanks!

The build id will most likely be a result of any differences, such as
those above.


Thanks for asking about reproducible builds in notcurses!


live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20201228/f40413fc/attachment.sig>