Unable to build newer versions of Fulcrum on macOS

[Francisco-DAnconia]

When building a version of Fulcrum newer than 1.9.x, I receive the following error in the project:

:-1: error: Project ERROR: Failed to detect either BIG or LITTLE endian. Unknown compiler? FIXME!

Perhaps my build environment has drifted out of date??

Monterey 12.7.6
Cmd Line Tools 14.2
QT Creator 8.0.0 w/ 5.15.2

gcc --version                                         
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: x86_64-apple-darwin21.6.0

Pretty much the same environment I've used from 1.70 through 1.9.7. Please advise.

[cculianu]

I've seen this error and the only solution is to blow away the build directory and re-create it. I think stale files in there cause this to happen. You are building from command-line or using Qt Creator?

EDIT: Your mention of Qt Creator leads me to think you are using Qt Creator. This has happened to me. I had to quit creator, blow away the build dir, then re-open the project and re-create the build dir (by re-opening the .pro file).

EDIT2: Also I noticed this happens more when attempting to use Qt5 with newer macs. Maybe might want to switch to Qt 6.x series...

[Francisco-DAnconia]

Thanks.

Assuming "build-Fulcrum-Desktop_Qt_5_15_2_clang_64bit-Release" is the build directory. When I delete it and re-open the project in QT Creator (still 8.0.0 ATM) the targets are not configured. I then configure the projects, on the Projects pane - just using the defaults.

Then I get the following slate of errors building Release.

[cculianu]

Fulcrum recently switched to C++20

It looks like it doesn’t acknowledge the need for C++20.. maybe try a newer qt creator …

[Francisco-DAnconia]

Forgive the naivety, my only Qt experience is building Fulcrum.

I installed the "Qt 6.8 for Desktop Development" from the qt_online_installer_macosx64-4.8.1 installer. I had to configure the project for targets (Qt 6.8.2) and was given a warning that cmake doesn't support the config generator. I configured. Now using Qt Creator 15.0.1.

Is that what you meant by "switching to Qt 6.x series..."?

Upon trying to build Release, I received a very similar set of errors my previous post.

It seems to me that Monterey doesn't have the toolset necessary to build C++20. What do you think?

[cculianu]

It seems to me that Monterey doesn't have the toolset necessary to build C++20. What do you think?

This is likely. I remember having trouble building C++20 stuff on older macOS. You can do something evil and use MacPorts (or Brew?) to install another newer clang complete with libc++, and tell Qt Creator to use that compiler rather than the system compiler.. and also statically link libc++ to Fulcrum, so that you end up not depending on the macOS C++ system libs and on Xcode at all..

I remember doing this at some point to get newer C++20 features in older macOS. But I honestly forgot how I got it working but I know it's possible.

Why not upgrade to latest macOS?

[Francisco-DAnconia]

Yes, Building with the latest Qt requires a recent macOS. The build footprint is also bigger, since it seems to also require Xcode instead of just the Command Line Utilities. It took me some time to start to understand Qt for Opensource and the required OSes.

I could never find older builds (that is, newer than 5.14 @ download.qt.io/archive/qt)

Is it true, that Qt will only allow you to download the most recent build for Opensource work?

Any chance macOS binary builds are in the pipeline?

I was finally able to build the project. Now I'm working on resolving run/launch issues.

[Francisco-DAnconia]

My node seems to be running fine on testnet and mainnet.

For those moving Fulcrum from a build machine to their node on macOS, the following libraries are required.

Just like 5.15.2, both QtCore.framework & QtNetwork.framework need to be in a relative path next to the binary (../Frameworks/QtSomething.framework)

But, 6.8.2 requires ../plugins/tls for : libqcertonlybackend.dylib, libqopensslbackend.dylib & libsecuretransportbackend.dylib. Otherwise there isn't SSL and the following runtime warnings appear:

[Qt Warning] No functional TLS backend was found (:0, )
[Qt Warning] No functional TLS backend was found (:0, )
[Qt Warning] No TLS backend is available (:0, )
[Qt Warning] No functional TLS backend was found (:0, )
[Qt Warning] No functional TLS backend was found (:0, )

[Francisco-DAnconia]

Just an FYI. I'm still seeing the following warnings on mainnet (≈4x/day) - you thought it was benign (Issue #141).

<SynchMempool> Synch mempool expected to drop 1460, but in fact dropped 1468 -- retrying getrawmempool
<SyncMempoolPreCache> SynchMempoolTask::Precache::threadFunc: Unable to find prevout a42571a38dfcc54ac9703f1f7e9e7e99b256724c586c8eaf52b8b3c43b41417a:0 in DB for tx b7fc8fd479f6c0b8b40d46f829e1392b1369653254b6bae505aab563a639696d (possibly a block arrived while synching mempool, will retry)
<SynchMempool> processResults: precache->thread errored out, aborting SynchMempoolTask
<Controller> Failed to synch blocks and/or mempool
<Controller> Block height 883373, downloading new blocks ...

<Controller> 1989 mempool txs involving 4710 addresses
<SynchMempool> Synch mempool expected to drop 1129, but in fact dropped 1157 -- retrying getrawmempool
<SyncMempoolPreCache> SynchMempoolTask::Precache::threadFunc: Unable to find prevout 00e85d9d0f6a26319e7d77cb0eca14c70b7877262ad5768132003c80229d1983:3 in DB for tx 9073c121dcbe33a2b2d9ad4ab88be071503e1358aba3e0fc4d438b374c0e2028 (possibly a block arrived while synching mempool, will retry)
<Controller> Failed to synch blocks and/or mempool

[cculianu]

Great work man! Sorry I didn't respond to you in due time.

Any chance macOS binary builds are in the pipeline?

I have to figure out how to do this on macos. Ideally I'd use docker or something but.. it's tricky on macos .. it just takes time I'm more familiar with Linux for this task.

you thought it was benign (Issue #141).

Yeah it's benign. It's literally that as it's trying to synch the mempool a block arrives and what it thought were "mempool txns" are confirmed now and disappear from the mempool or are block-only txns so their prevouts are not in mempool

It's fine and it's expected. Perhaps I should make the message less alarming.. maybe only show it if this happens often... hmm.

[Francisco-DAnconia]

No worries - everyone is busy.

It's fine and it's expected. Perhaps I should make the message less alarming.. maybe only show it if this happens often... hmm.

FWIW, when I see a yellow trace msg I don't worry too much. But when they're red, they grab my attention.
Both of these are red:

processResults: precache->thread errored out, aborting SynchMempoolTask
Failed to synch blocks and/or mempool

Perhaps an easy way to de-escalate the perceived severity is just make them yellow??

[cculianu]

Oh yeah I mean I never anticipated that to happen when developing -- but on BTC there's lots of "block only" txns (not in mempool) due to miners mining private txns at a discount -- I just brain farted and coded for that contingency to be an "OMG! Error!" so as to alert me as the developer if my code was buggy.

Turns out that it's not a real error -- it actually can happen and does happen.

Yeah I'll change it to yellow and maybe only switch to red if it happens too often (which would indicate an error in programming).

If you want, make an issue out of it!