Building KiCad 5.1.4 for Slackware

28 August 2019
I have been using KiCad v4.0.7 — a PCB design package — ever since I outgrew Fritzing, but the version of the latter was getting quite dated. Unfortunately KiCad is not the easiest pieces of software to get built, and this article covers what I did to get it working. Hopefully in the future it will be available via package management, but I suspect that may be some time off.


Most of the dependencies are standard Slackware packages, and of the remainder a few are available via SlackBuilds, the links for which are below if you don't already use SboPkg. Really all the dependencies should be available via SlackBuilds — there is even a SlackBuild, unfortunately broken, for KiCad v5.1.2 — but KiCad seems to use cutting-edge features of some of the libraries.


Although OpenCascade is available from SlackBuilds, that version does not include some cmake configuration files that are required, so I ended up building the upstream release of v0.18.3 from tar-ball:

mkdir build cd build cmake -DOCE_INSTALL_PREFIX:PATH=/opt/oce-0.18.3 .. make make install/strip


KiCad claims Boost v1.56 is required but when using v1.59.0 that is the current version in Slackware, the build process fails in what looks like unit-tests, and trying to disable them using KICAD_BUILD_QA_TESTS did not work. I ended up building v1.71 from upstream, which at time of writing is the latest version:

./ --prefix=/opt/boost-1.71.0 ./b2 ./b2 install


KiCad 5.x requires wxWidgets v3.x.x and I decided to save myself a lot of trouble and build the latest version from the upstream tar-ball. The one irritation is that the KiCad build system does not seem able to cope with statically-linking wxWidgets, so in the end I gave up and did a shared build:

./configure --prefix=/opt/wxWidgets-3.1.2/shared make make install


I am not sure whether wxPython scripting support is production quality, but I decided to disable it. KiCad requires it to be the Phoenix release available via pip, and it has to be built against the same wxWidgets libraries used to build KiCad itself, which is a source of endless trouble if they are not the system-wide ones.

A quick source change

Since I already have KiCad v4 on my system, I decided to make a change so that it uses a different configuration directory. In common/common.cpp at line 291 change:

cfgpath.AppendDir( wxT( "kicad" ) );


cfgpath.AppendDir( wxT( "kicad5.1.4" ) );

This causes KiCad to use ~/.config/kicad5.1.4 rather than ~/.config/kicad — I know that enviornment variables can achieve the same task, but I feel more comfortable if the compiled-in default is different.

Building & installing KiCad

Setup the build enviornment, and at this stage it will tell you if anything is missing:

mkdir -p build/release cd build/release cmake -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_INSTALL_PREFIX=/opt/kicad5.1.4 \ -DOCE_DIR=/opt/oce-0.18.3/lib/oce-0.18 \ -DBoost_DIR=/opt/boost-1.71.0/lib/cmake/Boost-1.71.0 \ -DwxWidgets_CONFIG_EXECUTABLE=/opt/wxWidgets-3.1.2/shared/bin/wx-config \ -DKICAD_SCRIPTING_WXPYTHON=OFF \ ../../

Once this is done, kick off the build itself and then install:

make make install

Finally I made a that fixes up the library paths. I know LD_LIBRARY_PATH is nasty, but being unable to do a static build it is the most expedient approach that does not pollute the system library paths:

#!/bin/bash LD_LIBRARY_PATH=/opt/wxWidgets-3.1.2/shared/lib LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/opt/oce-0.18.3/lib/ LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/opt/kicad5.1.4/lib64 LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/opt/kicad5.1.4/kicad/plugins/3d export LD_LIBRARY_PATH /opt/kicad5.1.4/bin/kicad


Usage of KiCad v5 itself is a future article for the electronics section once I have used it for a few projects. Nevertheless my immediate impression is that some of the rougher edges in v4 have been smoothed off, but changes to the component libraries mean that converting project files from v4 can be a pain. The library is far better organised, and I dare-say better stocked, but reassigning symbols and footprints is a pain. Tighter rules on the 3D models also means that a lot have now been removed. It is the future, but I am not sure when best to make the transition.