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

cmake: Add external signer support #79

Merged
merged 2 commits into from
Mar 7, 2024
Merged

Conversation

hebasto
Copy link
Owner

@hebasto hebasto commented Jan 19, 2024

A new configuration option is WITH_EXTERNAL_SIGNER.

Copy link

@pablomartin4btc pablomartin4btc left a comment

Choose a reason for hiding this comment

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

utACK 3371f3d

vcpkg.json Outdated Show resolved Hide resolved
@hebasto
Copy link
Owner Author

hebasto commented Jan 27, 2024

Rebased.

@hebasto hebasto added the enhancement New feature or request label Jan 27, 2024
@fanquake
Copy link

This branch works without the following workarounds from the master branch:

How is the first one fixed? I'm guessing it's because these checks are no-longer being run with same warning flags? I assume the second one is because -pthread is now just always being passed or something?

@hebasto hebasto force-pushed the 240118-cmake-AY branch 2 times, most recently from 8a05399 to dd11216 Compare January 29, 2024 16:20
@hebasto
Copy link
Owner Author

hebasto commented Jan 29, 2024

This branch works without the following workarounds from the master branch:

How is the first one fixed? I'm guessing it's because these checks are no-longer being run with same warning flags?

Thanks! Fixed.

@hebasto
Copy link
Owner Author

hebasto commented Jan 29, 2024

I assume the second one is because -pthread is now just always being passed or something?

Not so simple :)

I tried to reproduce the initial issue, which was fixed in bitcoin#24397, using for testing the 077cfff commit and commands as follows:

make -C depends -j $(nproc) NO_QT=1 NO_WALLET=1 NO_ZMQ=1 NO_UPNP=1 NO_NATPMP=1 NO_USDT=1 CC=gcc-10 CXX=g++-10
./autogen.sh && ./configure CONFIG_SITE=$PWD/depends/x86_64-pc-linux-gnu/share/config.site --enable-external-signer
  1. Ubuntu 20.04, libc 2.31 -- FAIL

config.log:

configure:26954: checking whether Boost.Process can be used
configure:26967: g++-10 -std=c++17 -o conftest -pipe -O2  -fno-extended-identifiers -I/bitcoin/depends/x86_64-pc-linux-gnu/include/  -DHAVE_BUILD_INFO -DPROVIDE_FUZZ_MAIN_FUNCTION -L/bitcoin/depends/x86_64-pc-linux-gnu/lib  conftest.cpp  >&5
/usr/bin/ld: /tmp/ccTX7pPT.o: in function `boost::asio::detail::posix_global_impl<boost::asio::system_context>::~posix_global_impl()':
conftest.cpp:(.text._ZN5boost4asio6detail17posix_global_implINS0_14system_contextEED2Ev[_ZN5boost4asio6detail17posix_global_implINS0_14system_contextEED5Ev]+0xa3): undefined reference to `pthread_join'
/usr/bin/ld: conftest.cpp:(.text._ZN5boost4asio6detail17posix_global_implINS0_14system_contextEED2Ev[_ZN5boost4asio6detail17posix_global_implINS0_14system_contextEED5Ev]+0xc4): undefined reference to `pthread_detach'
collect2: error: ld returned 1 exit status
  1. Ubuntu 22.04, libc 2.35 -- SUCCESS

FWIW, reading libc release notes did not give a clue.

@fanquake
Copy link

I would guess that's because recent versions of libc now include pthread, so pthread linking is no-longer required. I don't understand how this branch can drop the workaround in other cases, unless pthread is being linked some other way.

@fanquake
Copy link

FWIW, reading libc release notes did not give a clue.

It's in the 2.34 release notes: https://sourceware.org/pipermail/libc-alpha/2021-August/129718.html

In order to support smoother in-place-upgrades and to simplify
the implementation of the runtime all functionality formerly
implemented in the libraries libpthread, libdl, libutil, libanl has
been integrated into libc. New applications do not need to link with
-lpthread, -ldl, -lutil, -lanl anymore.

@hebasto
Copy link
Owner Author

hebasto commented Jan 29, 2024

Addressed @fanquake's comments. Add more CI jobs for Boost.Process edge cases.

Comment on lines 55 to 58
set(CMAKE_REQUIRED_FLAGS "${working_compiler_werror_flag}")
# Boost 1.78 requires the following workaround.
# See: https://github.com/boostorg/process/issues/235
string(APPEND CMAKE_REQUIRED_FLAGS " -Wno-error=narrowing")
Copy link
Owner Author

Choose a reason for hiding this comment

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

By default, CMake treats

include directories from the interfaces of consumed Imported Targets as system directories.

That means that we have --enable-suppress-external-warnings behaviour for granted.

If we won't bother to mirror the opposite behaviour, these 4 lines might be dropped.

@fanquake
Copy link

PR description needs updating?

@hebasto
Copy link
Owner Author

hebasto commented Jan 30, 2024

PR description needs updating?

Sure. Updated.

@hebasto
Copy link
Owner Author

hebasto commented Feb 9, 2024

Rebased.

if(WITH_EXTERNAL_SIGNER)
include(CheckCXXSourceCompiles)
set(CMAKE_REQUIRED_INCLUDES ${Boost_INCLUDE_DIR})
set(CMAKE_REQUIRED_FLAGS "${working_compiler_werror_flag}")
Copy link

@theuni theuni Feb 22, 2024

Choose a reason for hiding this comment

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

I don't think we actually want this on, do we? What if some future boost version has a non-fatal warning? Don't we only want the Wno-error in case a user has turned on Werror ?

Copy link
Owner Author

Choose a reason for hiding this comment

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

Yes, it does not correlate with the master branch (and I don't recall why I added it).

This line has been removed in the recent push to mirror the master branch behavior.

@theuni
Copy link

theuni commented Feb 23, 2024

Looks good to me other than the outstanding comments:

  • Werror question
  • @fanquake's request for a better comment re glibc.

@hebasto
Copy link
Owner Author

hebasto commented Feb 24, 2024

Thanks for review!

Looks good to me other than the outstanding comments:

  • Werror question

  • @fanquake's request for a better comment re glibc.

Updated per feedback.

Copy link

@pablomartin4btc pablomartin4btc left a comment

Choose a reason for hiding this comment

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

tACK aa53fe3

Optional packages:
  GUI ................................. Qt5
  external signer ..................... ON
  NAT-PMP ............................. ON
  UPnP ................................ ON
  ZeroMQ .............................. ON
  USDT tracing ........................ ON

Tested it quickly running rpc enumeratesigners successfully (doen't work without the external signer feature enabled returning Method not found).

./build/src/bitcoin-cli -signet -datadir=$HEBASTO_DATADIR enumeratesigners
error code: -1
error message:
Error: restart bitcoind with -signer=<cmd>

@m3dwards
Copy link

m3dwards commented Mar 7, 2024

ACK 617ef5b

Copied @pablomartin4btc trick for checking if signer support is available.

With cmake -S .. -DWITH_EXTERNAL_SIGNER=off:

➜  build git:(240118-cmake-AY) ./src/bitcoin-cli -regtest -datadir=/tmp/bitcoinddata enumeratesigners
error code: -32601
error message:
Method not found

With cmake -S .. -DWITH_EXTERNAL_SIGNER=on:

➜  build git:(240118-cmake-AY) ./src/bitcoin-cli -regtest -datadir=/tmp/bitcoinddata enumeratesigners
error code: -1
error message:
Error: restart bitcoind with -signer=<cmd>

Just as an aside, when I set external signer to "on" lowercase the print out after configure is: external signer ..................... ON in uppercase but when I set it to off lowercase the print out after configure is: external signer ..................... off in lowercase. Is this a cmake quirk?

" HAVE_BOOST_PROCESS
)
if(HAVE_BOOST_PROCESS)
if(WIN32)
Copy link

Choose a reason for hiding this comment

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

NIT: if it's WIN32 couldn't you just return early with external signer OFF and not bother checking if boost supports boost process? Would cleanup one nested if.

Copy link
Owner Author

@hebasto hebasto Mar 7, 2024

Choose a reason for hiding this comment

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

You are right. However, I've chosen this clumsy approach to mimic the Autotools' one for the sake of easier reviewing,

Anyway, this code will be gone after bitcoin#28981.

@hebasto
Copy link
Owner Author

hebasto commented Mar 7, 2024

@m3dwards

Just as an aside, when I set external signer to "on" lowercase the print out after configure is: external signer ..................... ON in uppercase but when I set it to off lowercase the print out after configure is: external signer ..................... off in lowercase. Is this a cmake quirk?

That is a flaw in tri-state option implementation. Anyway, it will be gone before merging into the master branch; see #83.

@hebasto hebasto merged commit 9a8c962 into cmake-staging Mar 7, 2024
25 checks passed
@pablomartin4btc
Copy link

I just found out that this feature is disabled for Windows build in master. For some more context see @Sjors comment.

@Sjors
Copy link

Sjors commented Mar 7, 2024

@pablomartin4btc indeed, though after bitcoin#28981 bringing back Windows should be doable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants