@nohea Thanks for the suggestion on using checkout (I usually just have used git clone).
I used those three commands: the autogen script, configure, make. Unfortunately, I had the same error running configure. Here’s the context to show it’s definitely choking on a boost sleep implementation somewhere:
checking for main in -lminiupnpc... yes
checking for boostlib >= (102000)... yes
checking whether the Boost::System library is available... yes
checking for exit in -lboost_system... yes
checking whether the Boost::Filesystem library is available... yes
checking for exit in -lboost_filesystem... yes
checking whether the Boost::Program_Options library is available... yes
checking for exit in -lboost_program_options... yes
checking whether the Boost::Thread library is available... yes
checking for exit in -lboost_thread... yes
checking whether the Boost::Chrono library is available... yes
checking for exit in -lboost_chrono... yes
checking whether the Boost::Unit_Test_Framework library is available... yes
configure: error: No working boost sleep implementation found
I didn’t run make this time because it’ll take a few minutes only to get to the point where the make util produces its version of that error.
When I type in sudo apt-get install libboost-all-dev
the output is:
Reading package lists... Done
Building dependency tree
Reading state information... Done
libboost-all-dev is already the newest version (1.65.1.0ubuntu1).
0 upgraded, 0 newly installed, 0 to remove and 39 not upgraded.
@peerchemist It’s interesting that it’ll accept Berkeley greater than 4.8 (I’ve found that some altcoins build but have a runtime error if you compile using 5.3 but the doc/build-unix.md file says it expects 4.8). [I’ve actually got two versions of libdb on my system and have been able to point programs being built to 4.8 when expected … I’m not sure why I’m having problems getting this thing to find a boost version that it likes]
$ dpkg -l ‘libdb*’ | grep ‘^ii’ # lists
ii libdb+±dev:amd64 1:5.3.21~exp1ubuntu2 amd64 Berkeley Database Libraries for C++ [development]
ii libdb4.8 4.8.30-xenial4 amd64 Berkeley v4.8 Database Libraries [runtime]
ii libdb4.8++ 4.8.30-xenial4 amd64 Berkeley v4.8 Database Libraries for C++ [runtime]
ii libdb4o8.0-cil 8.0.184.15484+dfsg2-3 all native OODBMS for CLI
ii libdb5.3:amd64 5.3.28-13.1ubuntu1.1 amd64 Berkeley v5.3 Database Libraries [runtime]
ii libdb5.3:i386 5.3.28-13.1ubuntu1.1 i386 Berkeley v5.3 Database Libraries [runtime]
ii libdb5.3++:amd64 5.3.28-13.1ubuntu1.1 amd64 Berkeley v5.3 Database Libraries for C++ [runtime]
ii libdb5.3+±dev 5.3.28-13.1ubuntu1.1 amd64 Berkeley v5.3 Database Libraries for C++ [development]
ii libdb5.3-dev 5.3.28-13.1ubuntu1.1 amd64 Berkeley v5.3 Database Libraries [development]
[…]
In this case when I ran configure with no fine-tuning I got output of:
checking for Berkeley DB C++ headers... default
configure: error: Found Berkeley DB other than 4.8, required for portable wallets (--with-incompatible-bdb to ignore or --disable-wallet to disable wallet functionality)
Whereas passing the option to configure as:
configure --with-incompatible-bdb
produces a warning in this block of output:
checking for Berkeley DB C++ headers... default
configure: WARNING: Found Berkeley DB other than 4.8; wallets opened by this build will not be portable!```
Pointing it to the instance of Berkeley DB 4.8 (ignoring my attempts to pacify it on the ongoing boost problem) seems to be the most optimal solution:
./configure LDFLAGS="-L${BDB_PREFIX}/lib/" CPPFLAGS="-I${BDB_PREFIX}/include/" --with-gui=qt5```
BTW, BDB_PREFIX was defined by changing into the working directory of BDB 4.8 and defining a variable in BASH: as BDB_PREFIX=$(pwd) # pointing this variable to that working directory – the root one for that BDB instance. Then the LDFLAGS passed to configure looks for those libraries and the CPPFLAGS looks for that include.
Anyhow, this satisfies the conditions where it’s looking for that version of BDB and I can keep the stock 5.3 version for compatibility with the rest of my system and that 4.8 on hand only for building coins that seem to want it.
That gets into an off-topic headache which is really bothering me with SSL/TLS and how I’m toying with downloading an older version of OpenSSL because many coins are using incompatibly old versions.
On my system:
$ openssl version
outputs: OpenSSL 1.1.0h 27 Mar 2018
BTW, Peercoin’s build-unix.md file lists the OpenSSL version used to compile as 1.0.1g – but I was under the impression that PPC had updated to interface using SSL versions beyond this. Simply as a reference, the main OpenSSL has this pertinent bit of support information:
"The latest stable version is the 1.1.1 series. This is also our Long Term Support (LTS) version, supported until 11th September 2023. Our previous LTS version (1.0.2 series) will continue to be supported until 31st December 2019 (security fixes only during the last year of support). The 1.1.0 series is currently only receiving security fixes and will go out of support on 11th September 2019. All users of 1.0.2 and 1.1.0 are encouraged to upgrade to 1.1.1 as soon as possible. The 0.9.8, 1.0.0 and 1.0.1 versions are now out of support and should not be used" [https://www.openssl.org/source/ ]
Hopefully that build-unix.md documentation just needs updating to reflect a more modern TLS.
I simply don’t have time (right now) to get properly versed in C++ interfacing with TLS (there’s a couple books that I’m looking to add to the shelf on this to read for understanding: Bulletproof SSL and TLS (2017 revision) by Ivan Ristic and Implementing SSL/ TLS Using Cryptography and PKI by Joshua Davies )