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

build: remove duplicate -lminiupnpc linking #28755

Merged
merged 2 commits into from
Nov 1, 2023

Conversation

fanquake
Copy link
Member

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:

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 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.

@DrahtBot
Copy link
Contributor

DrahtBot commented Oct 30, 2023

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage

For detailed information about the code coverage, see the test coverage report.

Reviews

See the guideline for information on the review process.

Type Reviewers
ACK hebasto, TheCharlatan, theuni, jonatack

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

@theuni
Copy link
Member

theuni commented Oct 30, 2023

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]
   )

@fanquake
Copy link
Member Author

fanquake commented Oct 30, 2023

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.

@theuni
Copy link
Member

theuni commented Oct 30, 2023

Right, but I'm not sure why we even want to continue performing a link check for each header (with the same lib).

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.

Seems simpler to check for each header we want, and do a single link check separately.

Sure, but it only makes sense to try to link once the headers have been found successfully. As-is in this PR, afaics, the AC_CHECK_HEADERS here is moot.

I don't really care much either way, configure.ac won't be around much longer :)

@theuni
Copy link
Member

theuni commented Oct 30, 2023

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:

Nevermind, this doesn't actually work. It stops at the first found header. Disregard :)

@fanquake
Copy link
Member Author

fanquake commented Oct 30, 2023

I don't really care much either way, configure.ac won't be around much longer :)

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.

Copy link
Contributor

@jonatack jonatack left a 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'.

Copy link
Contributor

@TheCharlatan TheCharlatan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 33fe16b

configure.ac Outdated Show resolved Hide resolved
configure.ac Outdated Show resolved Hide resolved
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.
Copy link
Member

@hebasto hebasto left a 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
...

Copy link
Contributor

@TheCharlatan TheCharlatan left a 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
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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])
Copy link
Member

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.

Copy link
Member

@theuni theuni left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK b74e449

@jonatack
Copy link
Contributor

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

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... no
...
checking whether to build with support for UPnP... yes
checking whether to build with support for NAT-PMP... no

this 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... no
...
checking whether to build with support for UPnP... yes
checking whether to build with support for NAT-PMP... no

@DrahtBot DrahtBot removed the request for review from jonatack October 31, 2023 23:31
@fanquake fanquake merged commit 9d594ed into bitcoin:master Nov 1, 2023
16 checks passed
@fanquake fanquake deleted the remove_duplicate_linking branch November 1, 2023 10:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants