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

Conversation

Projects
None yet
2 participants
@bmwiedemann
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.

Do not build two shared libraries
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.

Show comment
Hide comment
@bmwiedemann

bmwiedemann Oct 7, 2018

Contributor

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"

Contributor

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.

Show comment
Hide comment
@PJK

PJK Oct 7, 2018

Owner

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?

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

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.

Show comment
Hide comment
@bmwiedemann

bmwiedemann Oct 7, 2018

Contributor

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.

Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment