Building the KiCad EDA Suite from Sources

Page added June 6th, 2023, updated June 18th, 2026:

For electronic circuit board design, I use the KiCad EDA suite. This is a GPL-licensed free software application which began life at Cern many years ago and is now under continued (and I must say, quite aggressive) development by the for-profit KiCad Services Corporation and volunteers around the world. I think this software is a perfect example of how free software and commercial interests can benefit one another and from each other.

I recently built KiCad from the 10.0 branch on Ubuntu Linux 26.04 "Resolute" (see below).

Previously, I had built KiCad 7.0.5 on Debian GNU/Linux 11.x "Bullseye" (see further below).

2026 Update: Building on Ubuntu Linux 26.04 "Resolute"

This part written June 18th, 2026:

Note that I ran into some problems. The point of this article is to explain troubleshooting steps taken and lessons learned.

In /etc/apt/sources.list.d/ubuntu.sources, I added deb-src to the Types: lines:

## See the sources.list(5) manual page for further settings.
Types: deb deb-src
URIs: http://us.archive.ubuntu.com/ubuntu
Suites: resolute resolute-updates resolute-backports
Components: main universe restricted multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

## Ubuntu security updates. Aside from URIs and Suites,
## this should mirror your choices in the previous section.
Types: deb deb-src
URIs: http://security.ubuntu.com/ubuntu/
Suites: resolute-security
Components: main universe restricted multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

This is what I think I should have done next:

$ sudo add-apt-repository -s --yes ppa:kicad/kicad-dev-nightly
$ sudo apt update
$ sudo apt upgrade
$ sudo apt build-dep kicad-nightly

But I didn't know that, so this is what I actually did:

$ sudo apt update
$ sudo apt upgrade
$ sudo apt build-dep kicad

(Note the missing -nightly in the apt build-dep command.) Here's why that's a problem:

When I wrote the original article about building on Debian GNU/Linux 11.x "Bullseye" (see below), I wrote about the apt build-dep command (shown above). This command installs the dependencies needed to build a package from sources, with the following caveats: it can only install the dependencies it knows about. Suppose the package manager knows about an old version of a program. Just to illustrate, suppose it knows about KiCad 6.x (like "Bullseye" did). Suppose you're trying to build KiCad 7.x (like I did). If KiCad 7.x has new dependencies that KiCad 6.x didn't, apt build-dep won't know about them or install them. When I wrote the old article, I had to manually install the unixodbc-dev package because of that reason.

Well, KiCad 10.x did add a bunch of new dependencies since whatever was packaged with Ubuntu Linux 26.04. I expected that to be the case, so I went through the same motions, expecting to find and install missing dependencies as I learned about them. But (this is foreshadowing), that led to problems. But I didn't know that yet, so...

I fetched the KiCad sources:

$ mkdir ~/Builds
$ cd ~/Builds
$ git clone https://gitlab.com/kicad/code/kicad.git KiCad

And I switched to the 10.0 branch:

$ git checkout -b 10.0 origin/10.0

At the time, HEAD was at b41b0e5630a4d8d9a12cf4c142f5e07343811257. By the time I write this, a day later, several more bugs have been fixed on the branch.

And then I ran CMake to configure the build:

$ cd KiCad
$ mkdir -p build/release
$ cd build/release
$ cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo ../..

The RelWithDebInfo says we're building a "release" build, but with debugging information. This should help us provide the KiCad developers with useful information should we need to.

At this time, I should have disabled building the test suite, since I wasn't interested in running the tests. I just want to run the application. The test suite is disabled by turning off the KICAD_BUILD_QA_TESTS option, which is on by default.

I think it was at this time that I found out about one new dependency which had not been installed by apt build-dep kicad, libspnav-dev, which provides support for 3D space mice (6 degree-of-freedom mice). I went ahead and installed it:

$ sudo apt install libspnav-dev

I had to run CMake again:

$ cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo ../..

Now at this point, I could have just run make, but I didn't want to hog up the machine's entire CPU and run it hot with the fans sounding like a jetliner for a prolonged time while doing this build. It just so happens that on Linux, thanks to a kernel-level feature called cgroups and the controversial system management program systemd, which provides a convenient interface for it, there is a way to limit the CPU usage of a process (and all its subprocesses). I used that, and ran make this way:

$ systemd-run --user --wait --pipe --same-dir --property=CPUQuota=40% /usr/bin/make

Suffice it to say that if the build would have taken hours with full CPU utilization, it took even more hours when limited to forty percent CPU utilization.

I encountered some errors during the build. Unfortunately, I didn't keep a log of all the errors, but I know that I found out about two additional packages that were needed:

$ sudo apt install libwxgtk-webview3.2-dev
$ sudo apt install libpoppler-glib-dev

That libpoppler-glib-dev package turned out to be rather significant, because much later in the build process, this happened:

[ 88%] Linking CXX executable qa_eeschema
/usr/bin/x86_64-linux-gnu-ld.bfd: ../../../libs/kiplatform/libkiplatform.a(printing.cpp.o): in function `(anonymous namespace)::request_page_setup_callback(_GtkPrintOperation*, _GtkPrintContext*, int, _GtkPageSetup*, void*)':
/home/high12noon/Builds/Ubuntu/KiCad/libs/kiplatform/os/unix/printing.cpp:122:(.text+0x2c): undefined reference to `poppler_document_get_page'
/usr/bin/x86_64-linux-gnu-ld.bfd: /home/high12noon/Builds/Ubuntu/KiCad/libs/kiplatform/os/unix/printing.cpp:129:(.text+0x5a): undefined reference to `poppler_page_get_size'
/usr/bin/x86_64-linux-gnu-ld.bfd: ../../../libs/kiplatform/libkiplatform.a(printing.cpp.o): in function `(anonymous namespace)::draw_page(_GtkPrintOperation*, _GtkPrintContext*, int, void*)':
/home/high12noon/Builds/Ubuntu/KiCad/libs/kiplatform/os/unix/printing.cpp:48:(.text+0xde): undefined reference to `poppler_document_get_page'
/usr/bin/x86_64-linux-gnu-ld.bfd: /home/high12noon/Builds/Ubuntu/KiCad/libs/kiplatform/os/unix/printing.cpp:60:(.text+0x122): undefined reference to `poppler_page_get_size'
/usr/bin/x86_64-linux-gnu-ld.bfd: /home/high12noon/Builds/Ubuntu/KiCad/libs/kiplatform/os/unix/printing.cpp:92:(.text+0x176): undefined reference to `poppler_page_render'
/usr/bin/x86_64-linux-gnu-ld.bfd: ../../../libs/kiplatform/libkiplatform.a(printing.cpp.o): in function `(anonymous namespace)::begin_print_callback(_GtkPrintOperation*, _GtkPrintContext*, void*)':
/home/high12noon/Builds/Ubuntu/KiCad/libs/kiplatform/os/unix/printing.cpp:104:(.text+0x276): undefined reference to `poppler_document_get_n_pages'
/usr/bin/x86_64-linux-gnu-ld.bfd: ../../../libs/kiplatform/libkiplatform.a(printing.cpp.o): in function `KIPLATFORM::PRINTING::PrintPDF(std::__cxx11::basic_string, std::allocator > const&, bool)':
/home/high12noon/Builds/Ubuntu/KiCad/libs/kiplatform/os/unix/printing.cpp:157:(.text+0x308): undefined reference to `poppler_document_new_from_file'
/usr/bin/x86_64-linux-gnu-ld.bfd: /home/high12noon/Builds/Ubuntu/KiCad/libs/kiplatform/os/unix/printing.cpp:172:(.text+0x332): undefined reference to `poppler_document_get_n_pages'
collect2: error: ld returned 1 exit status
make[2]: *** [qa/tests/eeschema/CMakeFiles/qa_eeschema.dir/build.make:2865: qa/tests/eeschema/qa_eeschema] Error 1
make[1]: *** [CMakeFiles/Makefile2:8452: qa/tests/eeschema/CMakeFiles/qa_eeschema.dir/all] Error 2
make: *** [Makefile:166: all] Error 2

This error means that when linking qa_eeschema, it couldn't find the functions poppler_document_get_n_pages, poppler_document_get_page, poppler_document_new_from_file, poppler_page_get_size, and poppler_page_render.

It turns out that by not having libpoppler-glib-dev installed when CMake was run, a bunch of the files generated by CMake didn't instruct the build system to link to /usr/lib/x86_64-linux-gnu/libpoppler-glib.so. It only linked to /usr/lib/x86_64-linux-gnu/libpoppler.so. The missing functions are in the former, leading to this build failure.

It looks to me as though this is a bug in KiCad's CMake recipe: the build should not have proceeded without that needed library. Remember when I said I should have run some commands, but I actually ran others? KiCad's developers probably haven't encountered this failure mode because the build-dep from kicad-dev-nightly probably installs this needed library, so they haven't encountered the situation where CMake should have errored out and didn't, and they didn't encounter the linker errors.

Also, note that the error occurred while linking qa_eeschema, not eeschema. This is because of the other thing I should have done earlier: disable the KICAD_BUILD_QA_TESTS. Because I didn't do that, it built a tremendous amount of test suite stuff that I didn't want.

By the way, I was able to work around the qa_eeschema link error by going into build/release/qa/tests/eeschema/CMakeFiles/qa_eeschema.dir/link.txt and adding /usr/lib/x86_64-linux-gnu/libpoppler-glib.so to the link command manually. I also discovered later on that build/release/qa/tests/spice/CMakeFiles/qa_spice.dir/link.txt needed it as well, so I added it there, too. The build proceeded to completion...

...and then the built KiCad application wouldn't start because it couldn't find some of those poppler functions!

Evidently, qa_eeschema and qa_spice were linking to "that other" poppler library statically. But the KiCad application itself links libraries dynamically, and didn't know that it's supposed to link that one. So now it can't find those functions.

To fix it, I had to run those commands that I should have run in the first place:

$ sudo add-apt-repository -s --yes ppa:kicad/kicad-dev-nightly
$ sudo apt update
$ sudo apt upgrade
$ sudo apt build-dep kicad-nightly

That installs the build-dep for the latest version of KiCad (at least as long as the 10.x branch that I'm trying to build doesn't add new dependencies and I happen to try this process before the nightly PPA is updated. That could happen, but it's much less likely than with the older build-dep from the OS package manager.

And then I had to run the build again. Oh, I went ahead and disabled building the test suite, saving tremendous time.

References

Cgroups: Linux Cgroups at Wikipedia.

How to build KiCad on Linux (the easy way). Pay particular attention to the "Distro specific instructions." If you're building on Ubuntu, notice that "Ubuntu and all derivatives" is a link to:

How to build KiCad on Ubuntu (the easy way). Plot spoiler: Had I read this page before I began, I would have found out about sudo add-apt-repository -s --yes ppa:kicad/kicad-dev-nightly followed by sudo apt build-dep kicad-nightly, and that probably would have saved me all that trouble with libpoppler-glib-dev. As with all things related to Linux and building complex systems, your mileage may vary!

Quality assurance (QA) unit tests. This is where I found: "The KICAD_BUILD_QA_TESTS option allows building unit tests binaries for quality assurance as part of the default build. This option is enabled by default."

Original Article: Building on Debian GNU/Linux 11.x "Bullseye"

This part written June 6th, 2023:

I decided to install the latest KiCad EDA release, which at this writing (June 2023) is version 7.0.5, by building from sources. The target machine is running a recent install of Debian GNU/Linux 11.7, code-named Bullseye, for the x86_64 architecture. In fact, I just installed this operating system yesterday, since my other Debian installation, 10.x, code-named Buster, is using older versions of various software that I have wanted to update for quite some time now.

For this endeavor, I found the page How to build KiCad on Linux (the easy way) quite helpful. As the page points out, the trickiest part is making sure that the needed tools and dependencies are installed. At this writing, the page suggests the following for Debian Bookworm (currently a preview of what will eventually be the next major release of Debian GNU/Linux, version 12.x):

$ apt build-dep kicad

and

$ apt install unixodbc-dev

That build-dep command in particular is very cool: It does what its name suggests, which is to install the dependencies needed to build a package, rather than to install the package itself. This comes with a minor caveat, though: It installs the dependencies that are listed for the version of the package that it knows about. So, for example, if its kicad package installs, say, KiCad 6.x, and if we want to build KiCad 7.x, and if new dependencies have been added between those major releases, then build-dep will not know about the new dependencies and, it follows logically, will not install those.

Although the above suggestions were meant for Bookworm, they seemed to work correctly on Bullseye as well, with the above caveat, which we'll see momentarily...

Note: I don't know whether the above would install compiler tools like GCC and other tools needed for the build like CMake, because I already installed those kinds of development tools prior to starting this process. Among those, I installed the tools needed to provide a functional build environment for NuttX, using the notes I helpfully collected for myself, as well as for my worldwide readership, in Adventures with NuttX.

Somewhere in this process, I fetched the KiCad source code directly from its GitLab repository and switched to the 7.0.5 tag, which is the newest release at this writing, created the build directory, and entered it:

$ git clone https://gitlab.com/kicad/code/kicad.git
$ cd kicad
$ git checkout 7.0.5
$ mkdir build
$ cd build

I continued to follow the easy build instructions for KiCad, using cmake-gui for convenience. But as soon as I clicked the CMake GUI's "Configure" button, I ran into the first problem: My installed version of CMake, which in fact is the default one installed with sudo apt install cmake, was not new enough. This is something that comes up occasionally with Debian. On the one hand, the distribution is very stable, which provides a reliable experience. That's one of the big reasons I prefer Debian over other distributions. On the other hand, that stability comes at the cost of some lag between software releases and their appearance in the default Debian package repository. But the good news is that there is a workaround that allows one to install newer packages than those that are normally available for a given version of Debian: the "backports" repository.

I added the following lines to /etc/apt/sources.list:

# Added by high12noon on 2023-06-06 for newer versions of packages:
#
# According to https://backports.debian.org/Instructions/ the normal
# (non-backports) package will install by default. To install from
# backports, use:
#
# apt install <package>/bullseye-backports
# or
# apt install -t bullseye-backports <package>
deb http://deb.debian.org/debian bullseye-backports main
deb-src http://deb.debian.org/debian bullseye-backports main

Now, that by itself does not cause the newer programs to be installed; since packages from backports have duplicate names to those in the normal package repository, they are automatically given a lower priority. This means that the default (read: older) package will install unless we instruct apt otherwise.

Whenever we edit the list of package repositories, we have to tell apt to update its databases:

$ sudo apt update

Once that was done, I first removed the cmake and cmake-gui that were already installed:

$ sudo apt remove cmake cmake-gui

Then I installed cmake and cmake-gui from the backports repository as follows:

$ sudo apt install -t bullseye-backports cmake cmake-gui

I don't know whether it was actually necessary to remove the already-installed ones. Perhaps apt would be smart enough to update those packages. But I felt it was safer to do it this way.

With a new enough CMake installed, I once again brought up cmake-gui and clicked the "Configure" button. This time, it complained that harfbuzz was not found. It seems that apt build-dep kicad didn't install the harfbuzz-dev package. Perhaps this is a newer dependency in KiCad 7? I installed it with:

$ sudo apt install libharfbuzz-dev

and clicked "Configure" again. This time it worked, and I was able to move on to generating the Makefile by clicking "Generate."

From there, it was smooth sailing, except that it took a long time. Several hours, in fact. I navigated to the build directory where cmake-gui generated the Makefile and ran make. Several hours later, the build completed, and I was able to run sudo make install and run KiCad. Although the first build did take a long time, I think that if I ever decide to hack on KiCad or perhaps update to a newer release by switching the clone to a different tag or branch, a rebuild will probably take substantially less time, since it probably wouldn't be necessary to compile every single file.

As mentioned in How to build KiCad on Linux (the easy way), I had to run ldconfig to update the library caches, or else the PCB editor couldn't find needed libraries and therefore couldn't run.

And that's that! Now the real work begins, to make some circuit board designs...

Back to main page

Send feedback to: the name of this blog at mail dot com.