Compile SuSE Leap 15.3 + Boost 1.66

[Berthold_Benning]

Hi there,
SuSE Leap 15.3 now has problems compiling KiCAD with Boost version 1.66:

fatal error: boost/uuid/detail/random_provider.hpp: File not found
#include <boost/uuid/detail/random_provider.hpp>

[retiredfeline]

If you just want to run KiCad, you don’t need to compile, just get the kicad package from one of the community repos. The supporting packages are in the Electronics repo. Here’s my account of how I installed v6.

Migrating to v6 on openSUSE 15.3

This may help people who are using KiCad on openSUSE, which is currently at 15.3, with 15.4 expected in June. TL;DR: Just take the defaults and 99% will be done for you. At last I’m between projects and what’s more I have a board that I want to redo in v6 with SMT, so I have a point of comparison. Select repositories. Go to KiCad packages for openSUSE expand 15.3’s Show community packages. There are two user built contributions for 6.0.2 at the moment. Either one will do. Click on 1 Click In…

A couple of things:

1. My KiCad uses Boost 1.66 in the standard repo, so definitely it is possible to compile against and link with it if you really want to. You probably need to install the Boost development packages which contain the include files.

2. openSUSE is not one of the officially supported distros, so you won’t get anywhere reporting it as an issue, nonetheless packages are available or can be built, as you see above.

[Berthold_Benning]

Hi there,
I removed Boost version 1.66, then installed version 1.75 from the SuSE repositories and I was able to recompile KiCAD.
Best regards

[Stephen_Chivers]

This is due to a recent change in the file kiid.cpp located in the common directory.`

The most recent commit (d440ff7c) has an attempt to allow for compilation with boost 1.66 or later versions. This commit uses conditional compilation to sense the version of boost installed:

#if BOOST_VERSION >= 106700
static boost::uuids::detail::random_provider seeder; // required to ensure the rng has a random initial seed
#else
static boost::uuids::detail::seed_rng seeder; // required to ensure the rng has a random initial seed
#endif
static boost::mt19937 rng( seeder );
static boost::uuids::basic_random_generatorboost::mt19937 randomGenerator( rng );

I have been compiling the KICAD Nightlies intermittently on CentOS 8 systems and came across the problem last week. Up until this change, there was no problem with the Nightlies, they compiled and ran.

I am loath to install a later version of boost on these CentOS 8 systems. CentOS 9 Stream is missing a lot of the ‘development’ packages necessary to compile KICAD and its dependencies. So CentOS 9 isn’t an option from my point of view. A personal preference (for the moment) is to stay away from Fedora systems.

I think the fix for the branch supporting older versions of boost is:

#include <boost/random/seed_seq.hpp>
static boost::random::seed_seq seeder;

I think the fix I have used is equally applicable to the other conditional compilation branch, as the class boost::random::seed_seq is still present in versions of boost later than 1.66.

The subject code is about providing a seed sequence for the random number generator used to create a UUID to embed in a KICAD schematic.

One thing that is of concern with the original code is the use of a class from the detail namespace in boost, that is:

boost::uuids::detail::seed_rng

I think the fix I have used is equally applicable to the other conditional compilation branch which then eliminates the conditional compilation.

There is discussion in the git repository about the need to make version 1.67 of boost be the oldest supported version of boost for KICAD. I am not certain that this particular code example (commit d440ff7c) makes this necessary.

I am not sufficiently familiar with the boost UUID generator and its use in kiid.cpp to understand the impact of this.

[marekr]

@Stephen_Chivers

There is discussion in the git repository about the need to make version 1.67 of boost be the oldest supported version of boost for KICAD. I am not certain that this particular code example (commit d440ff7c) makes this necessary.

The goal to bump boost minimum is not just because of this issue but because as the rest of the world move it’s boost dependency up higher, the spread in API issues increases. Boost doesn’t do their API versioning using semver style so even a change from 1.67 to 1.68 of boost can have major API changes just because some maintainer of a boost package felt so. On our main supported platforms we are all >= 1.70 so are moving the baseline up.
As we move the baseline up, it also becomes possible to use newer boost packages that exist now and didn’t before.