-
Notifications
You must be signed in to change notification settings - Fork 37.8k
depends: Purge libtool archives #15844
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
depends: Purge libtool archives #15844
Conversation
a2d7d19
to
f05fbd4
Compare
I had to do this once for an embedded project, because the |
The result is usually You can expand "Old content no. 1" here for an example. |
This comes at my request, so concept ACK :) I suspect it may flesh out a few actual bugs, where we had assumed pkg-config was doing its job. |
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
@dongcarl Could you try this theuni@f643224 as a test fix for the new failure? |
@theuni Looking at the travis failures it's similar to something I've encountered before related to I can just push another commit that bumps |
@dongcarl Hah, yes, thanks for noticing. I just assumed ours wasn't ancient. Please include the bump with this PR, since it breaks the build without it. |
Looking at the Travis build logs for 27ce43d, it would seem that cross builds are running into another problem that I assumed to be specific to my particular configuration. Namely, that we need to give the config flag I've included that config flag in e5444bb, this seems to be a common problem for cross builds of X things: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861073 |
Concept ACK Looks like there is still at least one issue with the
This is the diff of
|
After depends building inside a
|
Ready for re-review. Checks are passing. |
Thanks, having a look at this. |
9f0bfd6
to
61e64c2
Compare
depends/packages/libXext.mk
Outdated
$(package)_dependencies=xproto xextproto libX11 libXau | ||
|
||
define $(package)_set_vars | ||
$(package)_config_opts=--disable-static | ||
$(package)_config_opts=--disable-static --enable-malloc0returnsnull |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I looked into this a few weeks back, and I believe this is auto-detected, but we manage to get it wrong.
Could you please explain exactly why this is necessary? I'm afraid we're accidentally building against system files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mentioned this a little here: #15844 (comment)
Also, it's recommended when cross-compiling here: https://www.x.org/wiki/CrossCompilingXorg/
Not 100% sure what you mean by "accidentally building against system files"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're completely right, thank you.
Could you add that link (or c/p the quote) as a comment? It's very helpful to know that it's for bypassing an AC_RUN_IFELSE.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, after looking at libXext's source I believe the stricter --disable-malloc0returnsnull
works as well (I also confirmed thru a gitian build). I'll update this.
8837d20
to
4d68df7
Compare
Updated with some commentary to help future cross-compilation target architectures/libcs. |
4d68df7
to
716afd6
Compare
Rebased. |
Gitian builds for commit 3001cc6 (master):
Gitian builds for commit fbf6a3e (master and this pull):
|
# commit, the AC_RUN_IFELSE block had an action-if-cross-compiling argument | ||
# which set the more pessimistic default value MALLOC_ZERO_RETURNS_NULL=yes. | ||
# This is why the flag was not required prior to libXext 1.3.3. | ||
$(package)_config_opts=--disable-static --disable-malloc0returnsnull |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've only looked into this briefly, but why does --disable-malloc0returnsnull
only get passed to libXext
?
With this change, building depends on Debian I'm seeing:
Configuring libX11...
checking whether malloc(0) returns NULL... yes
Configuring libXext...
checking whether malloc(0) returns NULL... no
Does this matter?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@fanquake Ah, that's the only place where I found problems. Looking at the libX11
aclocal.m4
, they haven't updated their xorg-macros
yet so no problems yet. We should add --disable-malloc0returnsnull
there as well just to future-proof. You didn't see any other malloc(0)
checks other than these two?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't seen any other malloc(0)
checks 👍.
tACK 716afd6
Building on macOS 10.14.x:
|
716afd6
to
6ef57ad
Compare
Updated to also enforce the stricter |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
re-tACK 6ef57ad
Secondary dependencies don't need to be shared.
We use pkg-config where we can, which generally replaces libtool at a higher level and does not have the same downsides as libtool. These archives sit in our depends tree with no purpose and pollute the final bitcoin build with massive overlinking.
Compilation error for _XEatDataWords fixed in bb24f29, first included in libXext 1.3.3.
6ef57ad
to
8541cbe
Compare
Update: Rebase on #16041. Sorry for updating this so often, want to make sure that once people with merge access approve, the whole process is smooth. |
ACK 8541cbe, code changes look good to me |
8541cbe depends: libX*: --disable-malloc0returnsnull in conf (Carl Dong) 0e75263 depends: libXext: Bump to 1.3.3 to fix _XEatDataWords (Carl Dong) 683b7d7 depends: Purge libtool archives (Carl Dong) 1420928 depends: Build secondary deps statically. (Carl Dong) Pull request description: ``` We use pkg-config where we can, which generally replaces libtool at a higher level and does not have the same downsides as libtool. These archives sit in our depends tree with no purpose and pollute the final bitcoin build with massive overlinking. ``` See [here](https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Handling_Libtool_Archives) for an explanation of the various problems libtool archives can cause. Unrelated in every way except in spirit: `-D__LIBTOOL_IS_A_FOOL__`!! ----- This PR is based on #16041, and therefore should be merged after #16041. ACKs for commit 8541cb: Tree-SHA512: 76030cf32361f0b1cfe14e3827a0cbec99994e7da00a56194ca40cf6cf7d87f78552f49d03d41ce9cf9b642992b90d993578ed1f0ad6bae15cd3f1c88dfaa4b0
8541cbe depends: libX*: --disable-malloc0returnsnull in conf (Carl Dong) 0e75263 depends: libXext: Bump to 1.3.3 to fix _XEatDataWords (Carl Dong) 683b7d7 depends: Purge libtool archives (Carl Dong) 1420928 depends: Build secondary deps statically. (Carl Dong) Pull request description: ``` We use pkg-config where we can, which generally replaces libtool at a higher level and does not have the same downsides as libtool. These archives sit in our depends tree with no purpose and pollute the final bitcoin build with massive overlinking. ``` See [here](https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Handling_Libtool_Archives) for an explanation of the various problems libtool archives can cause. Unrelated in every way except in spirit: `-D__LIBTOOL_IS_A_FOOL__`!! ----- This PR is based on bitcoin#16041, and therefore should be merged after bitcoin#16041. ACKs for commit 8541cb: Tree-SHA512: 76030cf32361f0b1cfe14e3827a0cbec99994e7da00a56194ca40cf6cf7d87f78552f49d03d41ce9cf9b642992b90d993578ed1f0ad6bae15cd3f1c88dfaa4b0
Summary: ``` We use pkg-config where we can, which generally replaces libtool at a higher level and does not have the same downsides as libtool. These archives sit in our depends tree with no purpose and pollute the final bitcoin build with massive overlinking. See here for an explanation of the various problems libtool archives can cause: https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Handling_Libtool_Archives ``` Backport of core [[bitcoin/bitcoin#15844 | PR15844]]. This does actually more that described, as it includes [[bitcoin/bitcoin#16041 | PR16041]] (it was merged as 1 PR instead of 2). Test Plan: Run the Gitian builds. Reviewers: #bitcoin_abc, deadalnix Reviewed By: #bitcoin_abc, deadalnix Differential Revision: https://reviews.bitcoinabc.org/D5621
Update ZeroMQ Includes changes cherry-picked from the following upstream PRs: - bitcoin/bitcoin#9254 - bitcoin/bitcoin#13578 - bitcoin/bitcoin#15844 - bitcoin/bitcoin#16370 - Only the ZeroMQ changes. - bitcoin/bitcoin#16949
Summary: ``` We use pkg-config where we can, which generally replaces libtool at a higher level and does not have the same downsides as libtool. These archives sit in our depends tree with no purpose and pollute the final bitcoin build with massive overlinking. See here for an explanation of the various problems libtool archives can cause: https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Handling_Libtool_Archives ``` Backport of core [[bitcoin/bitcoin#15844 | PR15844]]. This does actually more that described, as it includes [[bitcoin/bitcoin#16041 | PR16041]] (it was merged as 1 PR instead of 2). Test Plan: Run the Gitian builds. Reviewers: #bitcoin_abc, deadalnix Reviewed By: #bitcoin_abc, deadalnix Differential Revision: https://reviews.bitcoinabc.org/D5621
See here for an explanation of the various problems libtool archives can cause.
Unrelated in every way except in spirit:
-D__LIBTOOL_IS_A_FOOL__
!!This PR is based on #16041, and therefore should be merged after #16041.