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

Do not build two shared libraries #72

Merged
merged 1 commit into from Oct 7, 2018
Merged

Do not build two shared libraries #72

merged 1 commit into from Oct 7, 2018

Conversation

@bmwiedemann
Copy link
Contributor

bmwiedemann commented Oct 7, 2018

Without this patch, when building with make -j1
cmake would create and install two shared libraries
libcbor.so and libcbor.so.0.0.0
instead of creating libcbor.so as a symlink.
This broke verification of reproducible builds.

See https://reproducible-builds.org/ for why this matters.

Also, (like before) do not install libcbor.a
because static linking is bad for maintainability
(because all programs have to be re-built with fixed libraries)

This PR was done while working on reproducible builds for openSUSE.

Without this patch, when building with make -j1
cmake would create and install two shared libraries
libcbor.so and libcbor.so.0.0.0
instead of creating libcbor.so as a symlink.
This broke verification of reproducible builds.

See https://reproducible-builds.org/ for why this matters.

Also, (like before) do not install libcbor.a
because static linking is bad for maintainability
(all programs have to be re-built with fixed libraries)
@bmwiedemann

This comment has been minimized.

Copy link
Contributor Author

bmwiedemann commented Oct 7, 2018

autogenerated provenance graph for libcbor.so https://www.zq1.de/~bernhard/images/rb/libcbor-j1.svg - notice the tooltips for the two left-hand strands mentioning "cbor" and "cbor_shared"

@PJK PJK added the Build issues label Oct 7, 2018
@PJK

This comment has been minimized.

Copy link
Owner

PJK commented Oct 7, 2018

This is great, thank you, @bmwiedemann! And well spotted with the static library.

As a side question, is there some automated check I can use to keep libcbor verification-friendly in the future?

@PJK PJK merged commit 75a6cc7 into PJK:master Oct 7, 2018
2 checks passed
2 checks passed
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@bmwiedemann

This comment has been minimized.

Copy link
Contributor Author

bmwiedemann commented Oct 7, 2018

You can try to avoid the ~12 basic indeterminisms described in https://github.com/bmwiedemann/theunreproduciblepackage (e.g. 'race' in this case)

But you don't really need to, because I'll watch whatever goes into openSUSE ;-)
There are also continuous tests running for Debian, published at
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libcbor.html
but somehow they did not catch this case.

@bmwiedemann bmwiedemann deleted the bmwiedemann:static branch Mar 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.