-
Notifications
You must be signed in to change notification settings - Fork 35.5k
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
build: remove duplicate -lminiupnpc
linking
#28755
Conversation
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code CoverageFor detailed information about the code coverage, see the test coverage report. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. |
As suggested by the docs: "You can give it a value of ‘break’ to break out of the loop on the first match." Seems to work as intended: diff --git a/configure.ac b/configure.ac
index 9b4b9bd42b..fdefad609c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1423,7 +1423,7 @@ if test "$use_upnp" != "no"; then
CPPFLAGS="$CPPFLAGS $MINIUPNPC_CPPFLAGS"
AC_CHECK_HEADERS(
[miniupnpc/miniupnpc.h miniupnpc/upnpcommands.h miniupnpc/upnperrors.h],
- [AC_CHECK_LIB([miniupnpc], [upnpDiscover], [MINIUPNPC_LIBS="$MINIUPNPC_LIBS -lminiupnpc"], [have_miniupnpc=no], [$MINIUPNPC_LIBS])],
+ [AC_CHECK_LIB([miniupnpc], [upnpDiscover], [MINIUPNPC_LIBS="$MINIUPNPC_LIBS -lminiupnpc"; break], [have_miniupnpc=no], [$MINIUPNPC_LIBS])],
[have_miniupnpc=no]
) |
Right, but I'm not sure why we even want to continue performing a link check for each header (with the same lib). Seems simpler to check for each header we want, and do a single link check separately. |
This is intended to be a shorthand pattern for: "only do the link test if we've found the headers", otherwise attempting to link makes no sense.
Sure, but it only makes sense to try to link once the headers have been found successfully. As-is in this PR, afaics, the I don't really care much either way, |
Nevermind, this doesn't actually work. It stops at the first found header. Disregard :) |
I think my want to "fix" this is two fold. Simpler porting for cmake, when comparing link behaviour & similar. If these link warnings ever turn into link errors down the line, we'll have broken release branches for some amount of time. |
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.
Lightly tested ACK 33fe16b
It doesn't seem to diminish the overall volume of warnings much, but is perhaps worth improving if these warnings were to become errors.
Build output on ARM64 Ventura 13.6 with Homebrew clang version 17.0.3:
from this (on master)
ld: warning: -bind_at_load is deprecated on macOS
ld: warning: -bind_at_load is deprecated on macOS
ld: warning: ignoring duplicate libraries: '-levent', '-lminiupnpc'
ld: warning: -bind_at_load is deprecated on macOS
ld: warning: -bind_at_load is deprecated on macOS
ld: warning: -bind_at_load is deprecated on macOS
ld: warning: ignoring duplicate libraries: '-levent', '-lminiupnpc', 'libbitcoin_util.a'
ld: warning: -bind_at_load is deprecated on macOS
ld: warning: ignoring duplicate libraries: '-levent', '-lminiupnpc'
ld: warning: -bind_at_load is deprecated on macOS
ld: warning: -bind_at_load is deprecated on macOS
ld: warning: ignoring duplicate libraries: '-levent', '-lminiupnpc', 'libbitcoin_util.a'
ld: warning: -bind_at_load is deprecated on macOS
ld: warning: -bind_at_load is deprecated on macOS
ld: warning: -bind_at_load is deprecated on macOS
ld: warning: ignoring duplicate libraries: '-levent', '-lminiupnpc'
ld: warning: -bind_at_load is deprecated on macOS
ld: warning: ignoring duplicate libraries: '-levent', '-lminiupnpc'
Making all in doc/man
make[1]: Nothing to be done for `all'.
make[1]: Nothing to be done for `all-am'.
to this (on this branch)
ld: warning: -bind_at_load is deprecated on macOS
ld: warning: -bind_at_load is deprecated on macOS
ld: warning: ignoring duplicate libraries: '-levent'
ld: warning: -bind_at_load is deprecated on macOS
ld: warning: -bind_at_load is deprecated on macOS
ld: warning: ignoring duplicate libraries: '-levent'
ld: warning: -bind_at_load is deprecated on macOS
ld: warning: -bind_at_load is deprecated on macOS
ld: warning: ignoring duplicate libraries: '-levent'
ld: warning: -bind_at_load is deprecated on macOS
ld: warning: -bind_at_load is deprecated on macOS
ld: warning: ignoring duplicate libraries: '-levent'
ld: warning: -bind_at_load is deprecated on macOS
ld: warning: -bind_at_load is deprecated on macOS
ld: warning: -bind_at_load is deprecated on macOS
ld: warning: ignoring duplicate libraries: '-levent', 'libbitcoin_util.a'
ld: warning: -bind_at_load is deprecated on macOS
ld: warning: ignoring duplicate libraries: '-levent', 'libbitcoin_util.a'
ld: warning: -bind_at_load is deprecated on macOS
ld: warning: -bind_at_load is deprecated on macOS
Making all in doc/man
make[1]: Nothing to be done for `all'.
make[1]: Nothing to be done for `all-am'.
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.
ACK 33fe16b
33fe16b
to
9a82389
Compare
Having the link check in the header check loop means we get `-lminiupnpc -lminiupnpc -lminiupnpc` on the link line. This is unnecessary, and results in warnings, i.e: ```bash ld: warning: ignoring duplicate libraries: '-levent', '-lminiupnpc' ld: warning: ignoring duplicate libraries: '-levent', '-lminiupnpc' ld: warning: ignoring duplicate libraries: '-levent', '-lminiupnpc' ``` These warnings have been occurring since the new linker released with Xcode 15, and also came up in hebasto#34.
Consolidate the lib checking logic to be the same as miniupnpc.
9a82389
to
b74e449
Compare
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.
ACK b74e449, it fixes one issue mentioned in hebasto#34 (comment).
./configure
output:
- in the master branch:
...
checking for miniupnpc/miniupnpc.h... yes
checking for upnpDiscover in -lminiupnpc... yes
checking for miniupnpc/upnpcommands.h... yes
checking for upnpDiscover in -lminiupnpc... (cached) yes
checking for miniupnpc/upnperrors.h... yes
checking for upnpDiscover in -lminiupnpc... (cached) yes
checking whether miniUPnPc API version is supported... yes
checking for natpmp.h... yes
checking for initnatpmp in -lnatpmp... yes
...
checking whether to build with support for UPnP... yes
checking whether to build with support for NAT-PMP... yes
...
- in this PR branch:
...
checking for miniupnpc/miniupnpc.h... yes
checking for miniupnpc/upnpcommands.h... yes
checking for miniupnpc/upnperrors.h... yes
checking for upnpDiscover in -lminiupnpc... yes
checking whether miniUPnPc API version is supported... yes
checking for natpmp.h... yes
checking for initnatpmp in -lnatpmp... yes
...
checking whether to build with support for UPnP... yes
checking whether to build with support for NAT-PMP... yes
...
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.
ACK b74e449
[have_natpmp=no]) | ||
AC_CHECK_HEADERS([natpmp.h], [], [have_natpmp=no]) | ||
|
||
if test "$have_natpmp" != "no"; then |
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 think this is one of those cases where you need the funky xsyntax.
$have_natpmp
is either "no" or empty. IIRC empty can screw up test
on some shells.
This is usually avoided by either initializing to something or doing: if test "x$have_natpmp" != "xno"; then
.
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.
IIRC empty can screw up test on some shells.
I think bash fixed that in 1996, and we have since removed all the x-prefix usage from our build system. It'd be good to not have to reintroduce it.
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.
Lol, you trying to tell me something? :)
if test "$have_miniupnpc" != "no"; then | ||
AC_CHECK_LIB([miniupnpc], [upnpDiscover], [MINIUPNPC_LIBS="$MINIUPNPC_LIBS -lminiupnpc"], [have_miniupnpc=no], [$MINIUPNPC_LIBS]) |
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.
Same xsyntax thing here, but clearly it's not been an issue. Maybe the quotes are enough.
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.
ACK b74e449
ACK b74e449 Build output diff is the same as my previous #28755 (review), and with the latest push also see a similar improvement as reported by @hebasto in #28755 (review): master
this branch
|
Having the link check in the header check loop means we get
-lminiupnpc -lminiupnpc -lminiupnpc
on the link line.This is unnecessary, and results in warnings, i.e:
These warnings have been occurring since the new macOS linker released with Xcode 15, and also came up in hebasto#34.
There are other duplicate lib issues, i.e with
-levent
+-levent_pthreads -levent
, but those are less straight forward to solve, and won't be included here.