I seem to recall reading somewhere that the version requirement for boost has been upgraded to 1.75.
I’ve currently got boost 1.71.0.
Application: KiCad
Version: 6.0.5-a6ca702e91~116~ubuntu20.04.1, release build
Libraries:
wxWidgets 3.0.4
libcurl/7.68.0 OpenSSL/1.1.1f zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0 librtmp/2.3
Platform: Linux 5.13.0-27-generic x86_64, 64 bit, Little endian, wxGTK, xfce, x11
Build Info:
Date: May 4 2022 07:55:51
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
Boost: 1.71.0
OCC: 7.5.2
Curl: 7.83.0
ngspice: 36
Compiler: GCC 9.4.0 with C++ ABI 1013
Build settings:
KICAD_USE_OCC=ON
KICAD_SPICE=ON
Ah here it is: Compile SuSE Leap 15.3 + Boost 1.66 - #5 by marekr It seems that the baseline for KiCad has been increased to ≥ 1.70. My distro offers either 1.66 or 1.75, but the base project has gone further since: Boost Version History
It’s a pity if kicad 6 drops support of Boost 1.66 - CentOS 8 has 1.66
I understand that kicad 7 can have new requirements for all libraries, but I don’t understand why requirements change with time in bug-fix releases 6.0.X
The developers mailing list is the right place to try, see for example [Kicad-developers] Unable to build on Ubuntu 18.04 for 6.0 branch.
I agree … it is strange for a bug fix release policy
Moreover missing the ability to have kicad stable up to date on centos 8 is a pity that would afflict many uers
The problem is Centos isn’t a listed “Supported” distro. It could very well be that of the listed supported distro’s (Ubuntu, Debian, Arch, Fedora) the minimum version of that will be available once v7 is released at the end of the year
Ubuntu 20.04 has 1.67
Debian 9 Backports has 1.67
Arch has 1.78
Fedora 34 has 1.75
if it is any consolation, on gentoo we have the other end of the problems were riding “cutting edge” means things break - right now Mesa-22.1.0_rc5 is breaking vulkan
I was a system administrator in a Red Hat shop for a little while. NO ONE used it as a desktop though. We had 80 plus installs, mostly virtual machines, that ran RHEL. The old SA had just left for a gig at RedHat. He referred to Fedora users as their ‘test bed’. I think they had to put out a desktop friendly version just to keep testers.
RedHad had Centos as user test base…
Centos now has been “acquired” by rh to be a subsidiary of Red Hat - much as Fedora is today, becoming Centos stream.
CentOS Stream
Continuously delivered distro that tracks just ahead of Red Hat Enterprise Linux (RHEL) development, positioned as a midstream between Fedora Linux and RHEL.
Luckily, as OpenOffice got LibreOffice fork, Centos got Rocky Linux and Alma Linux.
Both are in sync with RH and as a community-supported, production-grade enterprise operating system and both are binary-compatible with Red Hat Enterprise Linux.
Rocky Linux is an open-source enterprise operating system designed to be 100% bug-for-bug compatible with Red Hat Enterprise Linux®. It is under intensive development by the community.
AlmaLinux An Open Source, community owned and governed, forever-free enterprise Linux distribution, focused on long-term stability, providing a robust production-grade platform. AlmaLinux OS is 1:1 binary compatible with RHEL® and pre-Stream CentOS.
Both can be a reliable solution for an industrial environment.
I just read somewhere they got a healthy cash infusion so if you’re looking for stability…
Still, not a distro I’d use for desktop. But, choice.
the problem imo is that has been dropped during a bug fix release
the same happened to ubuntu 18
As with any unsupported system, we will accept patches that allow KiCad to continue working on Ubuntu 18 (or anything else) as long as they don’t interfere with supported platforms or cause other issues.
Support for Ubuntu 18 wasn’t dropped during a bug fix release… it just happened to work before, and now doesn’t happen to work anymore due to the Boost version bump. We don’t have anyone on the dev team using or testing 18.04, which is what would be required to call it “supported”.
it seems the bump was not because of issues:
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.
still imo it is a strange move in a bug fix release
Sorry, I think we are not discussing support of Ubuntu or CentOS, but support of earlier Boost versions
Last time file INSTALL.txt was edited one year ago in kicad version 6.0-rc1
At that moment minimal versions of some packages were changed, support for Windows 7 was removed, but requirement on Boost was kept at “>= 1.59” and with such requirements final release 6.0 was built. So, to my mind, developers should try to keep all requirements unchanged, rather than expecting bug fixes from non-experts to keep kicad running with 1.59 <= Boost <= 1.66
None of us are experts in boost < 1.66 either. That’s why we haven’t fixed it. We have no setup or knowledge what the correct way to do it is.
Hi, Mark
Could you make a change proposed in another thread on the same subject ?
#include <boost/random/seed_seq.hpp>
static boost::random::seed_seq seeder;
And I can test this fix if you give me instructions how to do that
I use the “nightly” RPMS provided by KICAD at the Fedora Community Projects (COPR) Build System to build for CentOS 8. These are at https://copr.fedorainfracloud.org/groups/g/kicad/coprs/.
I had a patch that implemented the change quoted by s2x3 (sanya). But following Marks rationale for the choice of a newer version of boost I changed my approach. The rationale is provided in another thread for the compilataion of the KICAD Nightlies using a SUSE system: https://forum.kicad.info/t/compile-suse-leap-15-3-boost-1-66/34905
Now, I have built a version of boost 1.76 for my system as a RPM that installs in parallel with the CentOS 8 distribution version of boost (1.66). CentOS 8 has a similar package for boost 1.69 (boost169-1.69.0-4.el8.x86_64.rpm). My package used the boost169 Source RPM as a basis. This allows me to continue install the updates provided by CentOS 8 stream without conflicts over the version of boost installed.
The source RPM for boost 176 that I used came from the Fedora Build System (KOJI) and was boost-1.76.0-9.eln114.src.rpm. Note, as I understand it the ‘elnXXX’ signifies Enterprise Linux Next, packages with suffix ELN do not necessarily build on a CentOS 8 Stream system.
When I build a RPM for my own use I change the ‘dist’ macro to be ‘.sc’ so that I can recognise my own packages in a listing of installed software.
One merit in the implementation that Mark choose for the KIID class is that it does not need the “boost libraries”. That is a KICAD program prepared on a system (a VM) using my boost176 does not require that they be installed on another CentOS 8 system.
To use the “parallel” version of boost I have to alter the ‘spec’ file in the KICAD Nightly RPMS to add two lines to the cmake invocation:
-DBoost_DIR=/usr/lib64/boost176 \
-DBoost_INCLUDE_DIR=/usr/include/boost176
I have built kicad-6.0.5 for CentOS 8 from the SRC RPM on the Fedora KOJI by Stephen Falco with the minor change above applied. Kicad-6.0.6 installs and runs on my main systems, the demo projects open.
I built kicad-nightly-6.99.0-1.20220518git294b8e9 with just the boost176 change today. So far the nightly builds install and run with the demo projects opening.
Stephen.
1 Like
Correction: kicad-6.0.6 should be kicad-6.0.5
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.