From 0991401cddc9a6f67b5170dfebfaa2679a518f13 Mon Sep 17 00:00:00 2001 From: Cory Fields Date: Fri, 15 Aug 2014 12:19:11 -0400 Subject: [PATCH] build: Fix boost build on some platforms When the libpath doesn't line up with the value from config.sub, we don't find the correct path to boost's libs. This adds a hack to try another path before giving up. Should close #3219. Rebased-From: 54c7df81 --- doc/release-notes.md | 1 + src/m4/ax_boost_base.m4 | 6 ++++++ 2 files changed, 7 insertions(+) diff --git a/doc/release-notes.md b/doc/release-notes.md index be9c7d5ae76..e6e36b9c79e 100644 --- a/doc/release-notes.md +++ b/doc/release-notes.md @@ -67,6 +67,7 @@ Miscellaneous: - key.cpp: fail with a friendlier message on missing ssl EC support - Remove bignum dependency for scripts - Upgrade OpenSSL to 1.0.1i (see https://www.openssl.org/news/secadv_20140806.txt - just to be sure, no critical issues for Bitcoin Core) +- Fix boost detection in build system on some platforms Credits -------- diff --git a/src/m4/ax_boost_base.m4 b/src/m4/ax_boost_base.m4 index e025a7e1ca9..3f24d5ddc61 100644 --- a/src/m4/ax_boost_base.m4 +++ b/src/m4/ax_boost_base.m4 @@ -112,6 +112,12 @@ if test "x$want_boost" = "xyes"; then ;; esac + dnl some arches may advertise a cpu type that doesn't line up with their + dnl prefix's cpu type. For example, uname may report armv7l while libs are + dnl installed to /usr/lib/arm-linux-gnueabihf. Try getting the compiler's + dnl value for an extra chance of finding the correct path. + libsubdirs="lib/`$CXX -dumpmachine 2>/dev/null` $libsubdirs" + dnl first we check the system location for boost libraries dnl this location ist chosen if boost libraries are installed with the --layout=system option dnl or if you install boost with RPM