Compile fails on Ubuntu 20.04 LTS

[BrentBaccala]

System is Ubuntu 20.04 LTS. Bertini 2 is cloned from github.

configure runs fine.

Compilation in b2/core fails.

It seems to require bmp::variable_precision_options, which appears to have been introduced in Boost 1.77.

The configure script only checks for Boost 1.71, and the compilation instructions suggest that Ubuntu 20.04 LTS (with Boost 1.71 from apt) is a usable build system.

Probably the build instructions are outdated.

[BrentBaccala]

Even the recent Ubuntu 23.10 release (Mantic Minotaur) only provides Boost 1.74.

So I guess I have to compile Boost myself if I'm on an Ubuntu system, right?

[ofloveandhate]

Unfortunately, yes. I wish the boost versions provided by apt were more current. And, I found a bug in 1.82 that's fixed in 1.83, so 1.77 isn't even enough. (It's a minor bug, but it's there).

I am sorry the build instructions are out of date. I find it nearly impossible to keep up, as I teach ≥12 credits each semester, plus service. Plus, the general shit environment for trans people in the US has me deeply depressed. Working on b2 is incredibly satisfying, but I rarely find time or mental state for it.

I do have a student working on re-writing the build system from the autotools to CMake, which should dramatically improve the building process, and enable us to distribute using conda. So that's nice.

In general, though, bertini 2 is NOT stable, ready-to-rock software. It has some sweet features and I'm quite proud of it. But alas, I ended up at an undergraduate liberal arts school with a heavy teaching load and little time to work on it.

I hope this was helpful.

[ofloveandhate]

I regard b2 as an experimental piece of software. I hope you enjoy what experience you have with it. Sorry it's not what it's supposed to be. It's missing the numerical irreducible decomposition, and is not parallelized. Bertini 1 is much more complete. If you need a reliable system right now, please consider using Bertini 1.

[ofloveandhate]

One more:

I plan to add the NID to b2 in AY24-25. I have a year of sabbatical planned and included NID in the proposal, and I think I will be very successful.

[ofloveandhate]

ok, one more.

I had to add breaking changes to bring in bmp::variable_precision_options because of a breaking change in Boost.Multiprecision in 2017/2018. And since then I've found a number of bugs (which have been fixed!) in bmp. But it left b2 in a broken state for those earlier versions, and 1.82 is now required, with 1.83 or later to have hope of all unit tests passing.

Compilation of b2 is a bear. That's why my student is working on cmake and conda distribution. I thought conda installation was going to be easier, but it wasn't so we decided to switch build systems to enable conda distribution.

That's enough from me for now. Thanks for filing the issue.

[BrentBaccala]

Thanks for your reply, and your work on this program!

I'm trying to do a NID on a system of equations that runs out of memory with Bertini 1 on a 96 GB system.

I'm thinking about modifying the code to parallelize across multiple nodes, each with 96 GB, in hopes of successfully executing the decomposition.

So, I wanted to take a look at Bertini 2, since I'm already thinking that some coding is required, so it might be best to do any coding on the newer program.

What might we do to close this issue? Should I make a PR bumping the required version of Boost in configure.ac to 1.83?

[BrentBaccala]

P.S. I have nothing against you for being trans. This business of loving templates and error messages from the compiler, on the other hand...

[ofloveandhate]

Error messages, they're my best friend ;)

My least favorite bugs are the ones without error messages. There's one I've been hunting for nearly a decade now; I wish I could figure out the error message it should be generating!

[ofloveandhate]

To close the PR, I think bumping the required Boost version to 1.83 would be reasonable.

There is an alternative, which I thought of last night. One can clone Boost.Multiprecision from github and use the most recent version, and use an older Boost version for the rest of the libraries.

The simpler fix is the version bump, cuz then we know we get the thread options and the related bugfix. I would happily accept a PR from you.

[ofloveandhate]

I think you're describing parallelizing the NID algorithm in bertini 1. It's already parallelized, using mpi, so the paths to track are distributed across processes.

I wonder which aspect of bertini1 is causing you to go OOM. Is it something having to do with holding a ton of endpoints or startpoints in memory?

[BrentBaccala]

Where is the bug in 1.82? It is in Boost.Multiprecision? Is that the only part of Boost that we need 1.83 for?

[ofloveandhate]

It's in Boost.Multiprecision -- see Issue 551, and others. But mostly 551.

[ofloveandhate]

This is why you can use an older Boost for Bertini 2, and just provide a newer Boost.Multiprecision using with-boost-multiprecision option at configure-time. (exact option name may differ, it's not important at this moment).

[ofloveandhate]

I did update the build instructions in the wiki to explain why 1.83 is needed, and replaced the min version numbers with more correct ones.

[BrentBaccala]

I just created PR #193 to bump the required Boost version number.

I still had to comment out four destructors that inherited from bertini::System and triggered error messages like this:

In file included from src/system/start/total_degree.cpp:25:
./include/bertini2/system/start/total_degree.hpp:52:9: error: ‘static void bertini::System::operator delete(void*)’ is private within this context
   52 |   class TotalDegree : public StartSystem
      |         ^~~~~~~~~~~

That's a second pull request. I'll think about it some more, but compiling against Boost 1.83 and commenting out those four destructors got it to compile on Ubuntu 20.04 LTS

[BrentBaccala]

make check fails. Errors like this:

test/classes/function_tree_test.cpp:55:16: error: ‘bertini::Variable’ has not been declared
   55 | using bertini::Variable::Make;
      |                ^~~~~~~~

Not trying to be a pain. Just reporting what I'm seeing on Ubuntu 20.04 LTS.