Missing Boost::System on ARM Ubuntu 18.04 #17010

issue Sjors openend this issue on October 1, 2019
  1. Sjors commented at 10:24 am on October 1, 2019: member

    Following the Ubuntu instructions on an Orange Pi Plus 2e running Ubuntu Bionic (Armbian):

    0sudo apt-get install build-essential libtool autotools-dev automake pkg-config bsdmainutils python3 ccache
1sudo apt-get install libssl-dev libevent-dev libboost-system-dev libboost-filesystem-dev libboost-chrono-dev libboost-test-dev libboost-thread-dev
2./autogen.sh 
3./configure --disable-wallet --without-gui --disable-tests --disable-bench
4...
5checking for boostlib >= 1.47.0 (104700)... yes
6checking whether the Boost::System library is available... yes
7configure: error: Could not find a version of the Boost::System library!

    0Linux orangepiplus2e 4.19.57-sunxi [#5](/bitcoin-bitcoin/5/).90 SMP Fri Jul 5 17:58:43 CEST 2019 armv7l armv7l armv7l GNU/Linux

    As suggested on Stack Overflow, adding --with-boost-libdir=/usr/lib/arm-linux-gnueabihf works around the issue. But ideally ./configure should figure this out.

    I’ve installed Bitcoin Core on the same type of device before, also using Armbian, though this was over a year ago. I did not need the workaround back then.

  2. Sjors added the label Bug on Oct 1, 2019
  3. fanquake added the label Linux/Unix on Oct 1, 2019
  4. fanquake commented at 12:11 pm on October 1, 2019: member
    My guess is this was broken in #15461 when the boost_base.m4 was updated, but our libsubdirs patch was dropped. I will get our patch upstreamed then pull the latest macro down.
  5. MarcoFalke added this to the milestone 0.19.0 on Oct 1, 2019
  6. Sjors commented at 12:22 pm on October 1, 2019: member
    Ah excellent, I broke it :-)
  7. hebasto commented at 1:37 pm on October 1, 2019: member

    @Sjors

    Ah excellent, I broke it :-)

    This is not your fault ;)

    Try this patch:

     0diff --git a/build-aux/m4/ax_boost_base.m4 b/build-aux/m4/ax_boost_base.m4
 1index 16fa69b41..65a6379bd 100644
 2--- a/build-aux/m4/ax_boost_base.m4
 3+++ b/build-aux/m4/ax_boost_base.m4
 4@@ -123,6 +123,7 @@ AC_DEFUN([_AX_BOOST_BASE_RUNDETECT],[
 5     dnl are almost assuredly the ones desired.
 6     AS_CASE([${host_cpu}],
 7       [i?86],[multiarch_libsubdir="lib/i386-${host_os}"],
 8+      [armv7l],[multiarch_libsubdir="lib/arm-linux-gnueabihf"],
 9       [multiarch_libsubdir="lib/${host_cpu}-${host_os}"]
10     )
  8. Sjors commented at 2:54 pm on October 1, 2019: member
    @hebasto that patch does the trick (after running ./autogen.sh).
  9. hebasto commented at 4:45 pm on October 1, 2019: member

    My guess is this was broken in #15461 when the boost_base.m4 was updated, but our libsubdirs patch was dropped.

    The patch itself: 54c7df81f3e5f81cb91646acaf82074a3a6be3b2 from #4704.

  10. laanwj commented at 7:42 am on October 2, 2019: member

    My guess is this was broken in #15461 when the boost_base.m4 was updated, but our libsubdirs patch was dropped. I will get our patch upstreamed then pull the latest macro down.

    This is the second time this happens in a short while (#16803), let’s try to be more careful when reviewing m4 replacements.

  11. laanwj renamed this:
    Missing Boost::System on Ubuntu 18.04
    Missing Boost::System on ARM Ubuntu 18.04
    on Oct 2, 2019
  12. ryanofsky commented at 2:31 pm on October 2, 2019: member
    Is there an automated (travis) test that could catch this type of error in the future?
  13. Sjors commented at 4:16 pm on October 2, 2019: member
    Not this specific one, because we only cross-compile to ARM.
  14. laanwj commented at 5:30 pm on October 2, 2019: member
    If it wasn’t for boost, for some reason, not conforming to the normal convention for UNIX libraries (e.g. using pkg-config), we’d need a lot less custom m4 code.
  15. laanwj commented at 6:04 am on October 4, 2019: member
    It does look like the upstreaming is taking longer than expected. I don’t think it’s good to hold up rc1 on this, so going to push the fix to 0.19.0 only—master can wait for upstreaming.
  16. laanwj referenced this in commit cd1e7bb064 on Oct 4, 2019
  17. laanwj removed this from the milestone 0.19.0 on Oct 4, 2019
  18. HashUnlimited referenced this in commit 002959e61a on Nov 17, 2019
  19. fxtc referenced this in commit 618097fc75 on Nov 25, 2019
  20. fxtc referenced this in commit 7f9a153b7e on Nov 25, 2019
  21. laanwj commented at 11:45 am on December 12, 2019: member
    Looks like this still wasn’t pulled upstream. Maybe it’s time to pull this into master anyway, to avoid the problem recurring in 0.20.
  22. laanwj added this to the milestone 0.20.0 on Dec 12, 2019
  23. Sjors commented at 8:11 pm on December 13, 2019: member
    Let’s hold off on that until closer to the fork-off point. There’s seems to be some activity again upstream.
  24. laanwj commented at 10:28 am on December 15, 2019: member

    Yes, okay.

    In general I feel really uncomfortable with issues that have been fixed on a branch but not in master. In any case I’ve tagged this with 0.20.0 so that it should come up again before then…

  25. opacey referenced this in commit 278751ea11 on Dec 19, 2019
  26. deadalnix referenced this in commit 53a3ec1060 on Apr 1, 2020
  27. hebasto referenced this in commit 13dbc6c7ff on Apr 2, 2020
  28. hebasto referenced this in commit fba1719190 on Apr 2, 2020
  29. MarcoFalke removed this from the milestone 0.20.0 on Apr 4, 2020
  30. MarcoFalke added this to the milestone 0.21.0 on Apr 4, 2020
  31. MarcoFalke commented at 11:32 am on April 4, 2020: member

    Let’s hold off on that until closer to the fork-off point. There’s seems to be some activity again upstream.

    Any updates in upstream that we could use?

  32. hebasto commented at 1:54 pm on April 4, 2020: member

    Let’s hold off on that until closer to the fork-off point. There’s seems to be some activity again upstream.

    Any updates in upstream that we could use?

    Both PRs to upstream still open:

  33. hebasto commented at 10:29 pm on April 7, 2020: member

    Tested https://github.com/autoconf-archive/autoconf-archive/pull/214 on ODROID-HC1 (ARMv7l + Ubuntu 18.04.4): it works both with GCC 7.5.0 and Clang 6.0.0 compilers.

    Therefore, I’d suggest to drop https://github.com/autoconf-archive/autoconf-archive/pull/198 in favor of https://github.com/autoconf-archive/autoconf-archive/pull/214, and apply changes in master before 0.20 branch off.

    If no objections, going to replace #18501 accordingly.

  34. laanwj commented at 10:05 am on April 8, 2020: member

    I also think the other change has more chance of making it upstream. it’s much less controversial and basically

    0+      [armv7l],[multiarch_libsubdir="lib/arm-${host_os}"],
  35. laanwj closed this on Apr 8, 2020
  36. ftrader referenced this in commit def73e3596 on Aug 17, 2020
  37. PastaPastaPasta referenced this in commit 213d3f336b on Jun 27, 2021
  38. PastaPastaPasta referenced this in commit 9e6232d669 on Jun 28, 2021
  39. PastaPastaPasta referenced this in commit 3f7ed07a3e on Jun 29, 2021
  40. PastaPastaPasta referenced this in commit 1e5aacf9cd on Jul 1, 2021
  41. PastaPastaPasta referenced this in commit 84785e9b41 on Jul 1, 2021
  42. PastaPastaPasta referenced this in commit 51fb668c3a on Jul 14, 2021
  43. vijaydasmp referenced this in commit 71235217d9 on Dec 6, 2021
  44. Munkybooty referenced this in commit 8378856f32 on Dec 9, 2021
  45. vijaydasmp referenced this in commit bda934d329 on Dec 13, 2021
  46. Munkybooty referenced this in commit 432098c993 on Dec 23, 2021
  47. DrahtBot locked this on Feb 15, 2022


Sjors fanquake hebasto laanwj ryanofsky MarcoFalke

Labels
Bug Linux/Unix

Milestone
0.21.0

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-11-21 09:12 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me