Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

3.0.6: libzest.so is not reproducible #70

Open
dvzrv opened this issue Jan 24, 2022 · 4 comments
Open

3.0.6: libzest.so is not reproducible #70

dvzrv opened this issue Jan 24, 2022 · 4 comments

Comments

@dvzrv
Copy link
Contributor

dvzrv commented Jan 24, 2022

Hi! I've built 3.0.6 for zynaddsubfx 3.0.6 on Arch Linux. You can find the current PKGBUILD and all patches here: https://github.com/archlinux/svntogit-community/tree/packages/zynaddsubfx/trunk

Unfortunately the built libzest.so is not (bit-for-bit) reproducible, although all sources are pinned. I assume, that this is due to some code rendering parts of the output binary in a random order.

You can find the diffoscope output here: zynaddsubfx-3.0.6-diffoscope.log

@fundamental
Copy link
Member

I'd suspect the problem is either in the guts of mruby or it's this line needing a sort statement https://github.com/mruby-zest/mruby-zest-build/blob/master/Makefile#L16

@dvzrv
Copy link
Contributor Author

dvzrv commented Jan 24, 2022

If I understand that call in the Makefile correctly, then it can be replaced by

find mruby/build/host -type f \( -not -iwholename "*mrbc*" -a -not -iwholename "*bin*" -a -iname "*.o" \)

@dvzrv
Copy link
Contributor Author

dvzrv commented Jan 24, 2022

I can provide a PR to change that later, but it unfortunately does not repair the issues with reproducibility and even has the diffoscope log grow by 40Mb. I also removed the duplicate inclusion of ./deps/libnanovg.a there and wonder whether that has been there intentionally or not.

@fundamental
Copy link
Member

If it doesn't fix the issue, then I wouldn't suggest a PR. If that doesn't resolve it, then I suspect it's something inside the innards of mruby's build system. There's a variety of steps and without a fair amount of work breaking it down into smaller pieces I can't say for certain the source of the problem. Off the top of my head there's VM codegen, there's a variety of symbol collection passes, there's some autotools configuration in the regular expression gem, and a few other elements. Things are being run serially, so I would have thought it would have worked for reproducible builds, but I guess that isn't the case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants