The ubuntu build failed, not finding log4cpp. I can put that part back in, but I'm wondering if we need a regression against 3.10.

I'm going to think about the 3.8 issues.

Hi,

This seems to fail in:

• ArchLinux, which currently ships GNU Radio 3.10.2 (see this GitLab job).
• Fedora 38 Rawhide, which currently ships GNU Radio 3.10.3 (see this GitLab job).
• OpenSUSE Tumbleweed, which currently ships GNU Radio 3.10.3 (see this GitLab job).
• Debian sid, which currently ships GNU Radio 3.10.3(see this GitLab job).
• Ubuntu 22.04, which ships 3.10.1 (see this GitLab job).

We need to dig a little bit more.

As I suspected, this thread pulls long. Your GitLab jobs are instructive. I also came across dusty support for Debian 8, CentOS 7, and Ubuntu 14.04.

At issue is the difficulty in maintaining the GNSS-SDR shadow-versions of the GNU Radio provided CMake config file packages. What is the matrix of configurations that you believe need to be supported on next? The more and varied the versions, the harder this will be to maintain.

Note that GNU Radio 3.10 requires C++17, so older systems are going to have to be rev-locked at some point (and soon). It also requires, for GCC, version 9 or better.

My recommendation is that, if you have to build from source, then plan on building GNU Radio too (if your distro is ancient, like mine is).

A few notes. This change has exposed various issues outside of our control that need to be worked around:

• Ubuntu 20.04 installs gnuradio-dev (3.8.1) which in turn pulls in volk2 (2.2.1). That version of volk has a dependency on orc-0.4 that is not a package dependency. I updated the main.yml to pull it in
• Ubuntu 22.04 installs gnuradio-dev (3.10.1); the gnuradio::gnuradio-blocks target has an interface link dependency on sndfile::sndfile. This can't be found unless libsndfile1-dev is installed. That affects your GitLab job.
• CentOS 7 GitLab job needs to be updated to install and run cmake3 instead of cmake. I removed support for CMake < 3.7
• Fedora:rawhide (gnuradio 3.10.3) needs libsndfile1-devel and fftw-devel. Also, it can remove log4cpp-devel

I suspect the other variants will be similar; I'll update here as I work through them.

The MacOS failure is going to be tougher. I'm less sure how I'm going to reproduce that. Thus far, I've run in Docker containers, so the build is repeatable and clean every time.

The MacOS failure is going to be tougher. I'm less sure how I'm going to reproduce that. Thus far, I've run in Docker containers, so the build is repeatable and clean every time.

I ran on my Mac (12.4) and there were no errors

Closing, because next has moved on, but I'm not sure the issue is fixed yet