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: boost::process detection doesn't pass include directory #22269

Closed
laanwj opened this issue Jun 17, 2021 · 2 comments · Fixed by #22320
Closed

build: boost::process detection doesn't pass include directory #22269

laanwj opened this issue Jun 17, 2021 · 2 comments · Fixed by #22320

Comments

@laanwj
Copy link
Member

laanwj commented Jun 17, 2021

boost::process detection fails here (FreeBSD 13.0) with:

configure:32183: checking for Boost Process
configure:32196: c++ -std=c++17 -c -g -O2  -DHAVE_BUILD_INFO -D__STDC_FORMAT_MACROS -DPROVIDE_FUZZ_MAIN_FUNCTION conftest.cpp >&5
conftest.cpp:80:10: fatal error: 'boost/process.hpp' file not found
#include <boost/process.hpp>
         ^~~~~~~~~~~~~~~~~~~
1 error generated.
configure:32196: $? = 1

The header in question does exist in /usr/local/include/boost/process.hpp. However, no include path is passed?

For comparison, the preceding boost::filesystem check, which passes -I/usr/local/include succeeds:

configure:32026: checking for exit in -lboost_filesystem
configure:32051: c++ -std=c++17 -o conftest -g -O2  -DHAVE_BUILD_INFO -D__STDC_FORMAT_MACROS -DPROVIDE_FUZZ_MAIN_FUNCTION -I/usr/local/include  -L/usr/local/lib conftest.cpp -lboost_filesystem   -lboost_system >&5
configure:32051: $? = 0
configure:32061: result: yes
@laanwj laanwj added this to the 22.0 milestone Jun 17, 2021
@theStack
Copy link
Contributor

I can confirm the same behaviour on OpenBSD 6.9:

configure:31594: checking for Boost Process
configure:31607: c++ -std=c++17 -c -g -O2  -DHAVE_BUILD_INFO -D__STDC_FORMAT_MACROS -DPROVIDE_FUZZ_MAIN_FUNCTION conftest.cpp >&5
conftest.cpp:79:10: fatal error: 'boost/process.hpp' file not found
#include <boost/process.hpp>
         ^~~~~~~~~~~~~~~~~~~
1 error generated.
$ find / -name process.hpp
...
/usr/local/include/boost/process.hpp
...

laanwj added a commit to laanwj/bitcoin that referenced this issue Jun 21, 2021
Pass boost's build settings to boost-specific library detection. As
boost::process is header-only, setting the CPPFLAGS is enough, there is
no need to set LIBS.

Closes bitcoin#22269.
@jarolrod
Copy link
Member

Confirming the same behavior on my FreeBSD 13 machine; when trying to build off master:

checking for Boost Process... configure: error: Boost::Process is required for external signer support, but not available!

sidhujag pushed a commit to syscoin/syscoin that referenced this issue Jun 24, 2021
957f358 build: remove check for Boost Process header (fanquake)
df2c933 build: remove workaround for Boost and std::atomic (fanquake)
2bf2116 build: set minimum required Boost to 1.64.0 (fanquake)

Pull request description:

  Setting a newer minimum required Boost means we can remove the awkward header / compile check for Boost Process.

  If we don't do this, we should at-least make Boost Process being missing no longer a failure, otherwise anyone building using Boost < 1.64.0 would have to pass `--disable-external-signer` as well.

  The only system I can see that is affected here, (doesn't have new enough system packages) is Debian Oldstable. However, anyone compiling there, can use depends. They can also no-longer use the system GCC (6.0), and I'd assume would be using Clang 7, which would be the newest compiler available to them. It's extended, LTS support also end in 1 year from now, so anyone still using it should be considering upgrading.

  Debian Buster (Stable) has 1.67+, Ubuntu Bionic has 1.65+, any of the BSDs, recent Fedora, macOS etc all also have well and truly new enough Boost versions available.

  I think this is something we should just do for 22.0. If not, definitely for 23.0.

  Fixes bitcoin#22319. Compiling Bitcoin Core should work, as `windows.h` will be included.
  Alternative to bitcoin#22294.
  Would also close bitcoin#22269.
  bitcoin#19128 could be re-opened.

ACKs for top commit:
  laanwj:
    Tested ACK 957f358 that this fixes bitcoin#22269.
  MarcoFalke:
    review ACK 957f358

Tree-SHA512: a8ffa7933dce8bf994892ef16664103d7b4e1008e52628e9becb918a7727232dfb51b23100a82dc2b60cd9af5877abc32dc2d3754a7e1b3ac5410a92fdf393f3
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Aug 18, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
3 participants