Can't build on gentoo

[mikfire]

[primary ↑·15|]/home/me/brewtarget/mik)rm -rf build
[primary ↑·15|]/home/me/brewtarget/mik)mkdir build
[primary ↑·15|]/home/me/brewtarget/mik)cd build
[primary ↑·15|]me/brewtarget/mik/build)cmake ..
-- The CXX compiler identification is GNU 12.2.1
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Building brewtarget version 3.0.7
-- PROJECT_SOURCE_DIR is /home/mik/brewtarget/mik
-- Doing Debug build (DO_RELEASE_BUILD = OFF)
-- Using Qt version 5.15.8
CMake Error at /usr/lib64/cmake/Boost-1.81.0/BoostConfig.cmake:141 (find_package):
  Could not find a package configuration file provided by
  "boost_stacktrace_backtrace" (requested version 1.81.0) with any of the
  following names:

    boost_stacktrace_backtraceConfig.cmake
    boost_stacktrace_backtrace-config.cmake

  Add the installation prefix of "boost_stacktrace_backtrace" to
  CMAKE_PREFIX_PATH or set "boost_stacktrace_backtrace_DIR" to a directory
  containing one of the above files.  If "boost_stacktrace_backtrace"
  provides a separate development package or SDK, be sure it has been
  installed.
Call Stack (most recent call first):
  /usr/lib64/cmake/Boost-1.81.0/BoostConfig.cmake:262 (boost_find_component)
  /usr/share/cmake/Modules/FindBoost.cmake:594 (find_package)
  CMakeLists.txt:653 (find_package)

Any suggestions for how to get this build working?

[mikfire]

Could we maybe encapsulate the boost requirements in a variable, so that you have to throw a specific command line option or set an environmental variable to enable it? Or maybe not mark it as required?

For now, I've just removed all of the boost requirements from the CMakelists.txt, and I was able to compile and run.

[matty0ung]

I don't really know Gentoo that well. If it's got some built-in way for installing a recent version of Boost, then I would hope that would work. If not, then you can manually do what the bt script automatically does on Ubuntu:

$ cd ~
$ mkdir ~/boost-tmp
$ cd ~/boost-tmp
$ wget https://boostorg.jfrog.io/artifactory/main/release/1.80.0/source/boost_1_80_0.tar.bz2
$ tar --bzip2 -xf boost_1_80_0.tar.bz2
$ cd boost_1_80_0
$ ./bootstrap.sh
$ sudo ./b2 install
$ cd ~
$ sudo rm -rf ~/boost-tmp

That should result in all the Boost libraries being available in a place that CMake can find them.

[Scimmia22]

It's not a matter of a recent version of boost, you'll notice they have a more recent version than you do. It's that stacktrace_backtrace is an optional, non-default component.

[matty0ung]

Ah, OK I see, that explains it. So, yes, my workaround above should do the trick, I hope.

[Scimmia22]

But nobody is going to make a mess of their libs by doing that.

[matty0ung]

Well, I certainly wouldn't want to advocate making a mess. :smile_cat:

On Gentoo, how would you suggest that someone best install an optional, non-default component of Boost?

[Scimmia22]

They would need to rebuild the system boost package with that correct build option. Not sure if Gentoo has a USE flag set up for that or not.

[matty0ung]

Cool. Let's see if @mikfire has luck with that.

[Scimmia22]

If there's a USE flag, that can be a good option for Gentoo, but it doesn't translate well to binary distros. Arch doesn't have it. Fedora doesn't have it. openSUSE doesn't have it. It appears to require a GCC component that isn't installed by default.

Edit: ref https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66570

[penguinpee]

I'm hitting the exact same error as @mikfire trying to build 3.0.7 for Fedora. Fedora rawhide has been updated to Boost 1.81 recently. There's a whole bunch of boost packages pulled in when building, but none appears to provide that optional component.

I'll check with fellow packagers if there's something I need to change in the package config. But a flag for toggling boost_stacktrace_backtrace on and off would be most welcome.

[Scimmia22]

for now, line 19 at https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=brewtarget#n19

[penguinpee]

Thanks! I'll do that if there's no other option (e.g. something providing stacktrace_backtrace). Since the current stable release (F37) does not have a recent enough version of boost, I cannot update Brewtarget at the moment, anyway. Rawhide will become F39 - to be released in fall.

Having said that, the upcoming F38 is on Boost 1.78 (same as F37). Is there a way of lowering the required boost version, so F38 can be shipped with the most recent release of Brewtarget?

[rodgert]

Having said that, the upcoming F38 is on Boost 1.78 (same as F37). Is there a way of lowering the required boost version, so F38 can be shipped with the most recent release of Brewtarget?

Boost.Stacktrace has shipped since 1.65.0 so lowering the requirement should 'just work'.

[Scimmia22]

The issue isn't boost_stacktrace, it's boost_stacktrace_backtrace, which as far as I can tell, only exists in Debianland.

As for the version requirement, see https://github.com/Brewtarget/brewtarget/blob/develop/CMakeLists.txt#L631

[penguinpee]

Feedback I've got from the libboost package maintainer for Fedora/RHEL:

Fedora does not provide libbacktrace, so Boost can't build against it.

That leaves me with patching it out as suggested by @Scimmia22, unless this can be changed to make use of the available libraries, which are:

/usr/lib64/libboost_stacktrace_addr2line.so.1.78.0
/usr/lib64/libboost_stacktrace_basic.so.1.78.0
/usr/lib64/libboost_stacktrace_noop.so.1.78.0

More info is available in the downstream bug.

[matty0ung]

Ah, OK, good to know. Thanks for finding this out.

Should be possible to change the build scripts either (a) to detect whether libbacktrace is present and, if not, fall back to something else or (b) accept a config flag to build against one of the other stracktrace libraries. I'll have a look after I'm done with https://github.com/Brewtarget/brewtarget/issues/733.

[penguinpee]

Thanks. I'm in no hurry and I haven't heard any users yet asking for a package update.

I'll have a look after I'm done with #733

Your locale should handle those. :stuck_out_tongue_winking_eye:

[penguinpee]

Since there's now a request for an update of the Fedora RPM (#770), I will apply the patch for now. But it would be nice to have this as a conditional or fully automated detection.

[penguinpee]

I'm wondering why there is a configurable minimal Boost version in meson.build

https://github.com/Brewtarget/brewtarget/blob/e5dc7bad92c6ff27cbd96f8206ef0aa54e621733/meson.build#L415

when this version gets hard coded in CMakeLists.txt

https://github.com/Brewtarget/brewtarget/blob/e5dc7bad92c6ff27cbd96f8206ef0aa54e621733/CMakeLists.txt#L646

In other words, modifying meson.build wrt Boost version has no effect when CMakeLists.txt is parsed.

[matty0ung]

I'm wondering why there is a configurable minimal Boost version in meson.build

https://github.com/Brewtarget/brewtarget/blob/e5dc7bad92c6ff27cbd96f8206ef0aa54e621733/meson.build#L415

when this version gets hard coded in CMakeLists.txt

https://github.com/Brewtarget/brewtarget/blob/e5dc7bad92c6ff27cbd96f8206ef0aa54e621733/CMakeLists.txt#L646

In other words, modifying meson.build wrt Boost version has no effect when CMakeLists.txt is parsed.

There is no special reason. I spent a lot of time fighting with CMake (and in particular with CPack, which we no longer use). I thought I'd try out Meson and I found it "cleaner" and more consistent, so I added it as a build mechanism -- and it's what I use personally day-to-day. I didn't want to kill off CMake because I know it's the "de facto" standard and a lot of people even prefer to use it. So, for now, any time I make a change to the build, I try to make the same change to both the CMake and Meson build files. (This is usually pretty trivial.)

We do all the overnight builds in both CMake and Meson, so they should both work. (But we don't do packaging with CMake/CPack because it was just too much pain trying to get it to work on Mac.)

I agree it would be nice for CMake and Meson to share some of their config. I didn't look into it, but am very open to ideas and suggestions.

[penguinpee]

Thanks for the explanation. I clearly haven't had enough caffeine yet to realize that meson.build and CMakeLists.txt are not related, but belong to different build systems.

I'm trying to switch to the Meson build for Fedora. Patched out the Boost stacktrace_backtrace dependency just to hit another showstopper:

meson.build:1086:3: ERROR: Program or command 'lupdate' not found or not executable

It seems nothing provides lupdate in Fedora. Would you happen to have a link to the upstream source?

[penguinpee]

Nevermind. Found it. It's part of qt5-linguist. The binary is in an odd location (/usr/lib64/qt5/bin/lupdate), that's why I didn't find it.

[ekaats]

Hi, I'm running into the same issues. Should modifying the meson.build or cmakelists.txt be enough? It hasn't worked for me at least.