ElementsProject/elements

Build error in master

Closed this issue · 5 comments

grubles commented

Not sure if you guys are aware of this already. Running commit df8e572 on Fedora 38.

$ gcc --version
gcc (GCC) 13.2.1 20231011 (Red Hat 13.2.1-4)

  CXX      support/libbitcoin_util_a-lockedpool.o
support/lockedpool.cpp: In member function ‘void Arena::free(void*)’:
support/lockedpool.cpp:102:20: error: ‘runtime_error’ is not a member of ‘std’
  102 |         throw std::runtime_error("Arena: invalid or double free");
      |                    ^~~~~~~~~~~~~
support/lockedpool.cpp:25:1: note: ‘std::runtime_error’ is defined in header ‘<stdexcept>’; did you forget to ‘#include <stdexcept>’?
   24 | #include <algorithm>
  +++ |+#include <stdexcept>
   25 | #ifdef ARENA_DEBUG
support/lockedpool.cpp: In member function ‘void LockedPool::free(void*)’:
support/lockedpool.cpp:327:16: error: ‘runtime_error’ is not a member of ‘std’
  327 |     throw std::runtime_error("LockedPool: invalid address not pointing to any arena");
      |                ^~~~~~~~~~~~~
support/lockedpool.cpp:327:16: note: ‘std::runtime_error’ is defined in header ‘<stdexcept>’; did you forget to ‘#include <stdexcept>’?
make[2]: *** [Makefile:11455: support/libbitcoin_util_a-lockedpool.o] Error 1
delta1 commented

looks specific to fedora 38

@psgreco do you have a back port commit that fixes this?

@grubles can you try the elements-23.x branch please

grubles commented

Looks to be this? bitcoin/bitcoin#26924

Trying elements-23.x now.

grubles commented

elements-23.x branch builds successfully.

  • 👍1
delta1 commented

Looks to be this? bitcoin/bitcoin#26924

yeah looks like it. it's backported to 23.x but hasn't landed in master yet, you'll have to cherry-pick it if you specifically need master

psgreco commented

Yes, sorry I saw this too late, but yes, this is a classic case where the "release" branch is in better shape than master because master needs to wait for the patch to come in from the normal merging process, while in the release branch we have much more flexibility.

#1142 is a previous case of the same problem

  • 👍1