Has anybody had success building Kicad on Windows 10 recently

I have tried for a number of days to build Kicad from source under WIndows 10.

I have followed the instructions exactly at http://docs.kicad.org/doxygen/md_Documentation_development_compiling.html#build_windows (both the easy way and hard way). These crap out with errors related to making a component. I filed a bug report (https://bugs.launchpad.net/kicad/+bug/1752150) but there has been no action/reply.

I also tried using kicad-winbuilder. It also craps out (not surprising given both are based on msys2. I also filed a bug report on that https://github.com/KiCad/kicad-winbuilder/issues/58. There was a bit of back and forth discussion but nothing remotely useful. Kicad-winbuilder is a bit of a problem because it wants to install Msys2 every time you run it. Kicad-winbuilder also has obsolete instructions for updating though, as I note in my bug report, even the updated one (pacman -Syuu) doesnā€™t work the way it is supposed to. (It works fine in my other instance of msys2.

Obviously, the issue could be with my set up although I use msys2 regularly for development. Nonetheless, both make instructions work with msys2 and they could be out of sync with updates to msys2.

Any help/guidance would be appreciated.

I havenā€™t tried this, but what happens if you try to install the OCE binaries with pacman, like:
pacman -S mingw-w64-x86_64-oce ?

Unfortunately I am an idiot with respect to Linux so I tried to make the OCE binaries and that failed as well (there appear to be make-related issues with OCE).

I will try your suggestion. Thanks!

Hmmm. Seems to be getting much farther: I seem to be compiling kicad ā€¦

Iā€™ll update what happens and, if that was the fix, notify Kicad devs crediting you!

Alas, it looked promising: ran for an hour or two, generating almost 7000 lines of console output, then said this

==> Finished making: mingw-w64-kicad-git r9689.5bbb4489b-1 (Mon, Mar 5, 2018 1:09:33 PM)
==> Installing package mingw-w64-x86_64-kicad-git with pacman -Uā€¦
loading packagesā€¦
resolving dependenciesā€¦
looking for conflicting packagesā€¦

Packages (1) mingw-w64-x86_64-kicad-git-r9689.5bbb4489b-1

Total Installed Size: 3316.33 MiB

Thereafter it worked for a few minutes longer and said this
ā€“ Looking for C:/MinGW/home/BrianP/src/MINGW-packages/mingw-w64-kicad-git/src/build-i686-w64-mingw32/CMakeFiles/CMakeTmp/CheckSymbolExists.cxx
ā€“ Looking for C:/MinGW/home/BrianP/src/MINGW-packages/mingw-w64-kicad-git/src/build-i686-w64-mingw32/CMakeFiles/CMakeTmp/CheckSymbolExists.cxx - not found

which I find odd: why is it trying to make i686 instead of 64 bit?

Anyhow a bit later it threw out
CMake Error at CMakeLists.txt:583 (find_package):
By not providing ā€œFindOCE.cmakeā€ in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by ā€œOCEā€, but
CMake did not find one.

Could not find a package configuration file provided by ā€œOCEā€ (requested
version 0.16) with any of the following names:

OCEConfig.cmake
oce-config.cmake

Add the installation prefix of ā€œOCEā€ to CMAKE_PREFIX_PATH or set ā€œOCE_DIRā€
to a directory containing one of the above files. If ā€œOCEā€ provides a
separate development package or SDK, be sure it has been installed.

========================================================

When I look for these files they are not found
$ find /home -name ā€œo*.cmakeā€
/home/BrianP/src/MINGW-packages/mingw-w64-oce/src/oce-OCE-0.17.2/adm/cmake/config/oce_build_config.h.cmake
/home/BrianP/src/MINGW-packages/mingw-w64-oce/src/oce-OCE-0.17.2/adm/cmake/config/oce_build_paths.h.cmake
/home/BrianP/src/MINGW-packages/mingw-w64-oce/src/oce-OCE-0.17.2/adm/cmake/config/oce_install_config.h.cmake

I figured Iā€™d try make OCE (why not) so I typed
$ makepkg
==> ERROR: pkgname is not allowed to start with a hyphen.

==> ERROR: An unknown error has occurred. Exitingā€¦

I am going to completely reinstall Msys2 and try again ā€¦

I did a complete clean MSYS2 install and managed to figure out how to set OCE_DIR. I fail the exact same way.

I looked at the error logs and noted the following compile errors

collect2.exe: error: ld returned 1 exit status

make[1]: *** [CMakeFiles/cmTC_2bb84.dir/build.make:99: cmTC_2bb84.exe] Error 1
make[1]: Leaving directory ā€˜/home/BrianP/src/MINGW-packages/mingw-w64-kicad-git/src/build-i686-w64-mingw32/CMakeFiles/CMakeTmpā€™
make: *** [Makefile:126: cmTC_2bb84/fast] Error 2

Determining if the getc_unlocked exist failed with the following output:
Change Dir: C:/msys64/home/BrianP/src/MINGW-packages/mingw-w64-kicad-git/src/build-i686-w64-mingw32/CMakeFiles/CMakeTmp

Run Build Command:ā€œC:/msys64/usr/bin/make.exeā€ ā€œcmTC_6a36b/fastā€
/usr/bin/make -f CMakeFiles/cmTC_6a36b.dir/build.make CMakeFiles/cmTC_6a36b.dir/build
make[1]: Entering directory ā€˜/home/BrianP/src/MINGW-packages/mingw-w64-kicad-git/src/build-i686-w64-mingw32/CMakeFiles/CMakeTmpā€™
Building C object CMakeFiles/cmTC_6a36b.dir/CheckSymbolExists.c.obj

/C/msys64/mingw32/bin/gcc.exe -march=i686 -mtune=generic -O2 -pipe -o CMakeFiles/cmTC_6a36b.dir/CheckSymbolExists.c.obj -c /C/msys64/home/BrianP/src/MINGW-packages/mingw-w64-kicad-git/src/build-i686-w64-mingw32/CMakeFiles/CMakeTmp/CheckSymbolExists.c
C:/msys64/home/BrianP/src/MINGW-packages/mingw-w64-kicad-git/src/build-i686-w64-mingw32/CMakeFiles/CMakeTmp/CheckSymbolExists.c: In function ā€˜mainā€™:

C:/msys64/home/BrianP/src/MINGW-packages/mingw-w64-kicad-git/src/build-i686-w64-mingw32/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8:19: error: ā€˜getc_unlockedā€™ undeclared (first use in this function); did you mean ā€˜_getc_nolockā€™?

return ((int*)(&getc_unlocked))[argc];

               ^~~~~~~~~~~~~

               _getc_nolock

C:/msys64/home/BrianP/src/MINGW-packages/mingw-w64-kicad-git/src/build-i686-w64-mingw32/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8:19: note: each undeclared identifier is reported only once for each function it appears in

make[1]: *** [CMakeFiles/cmTC_6a36b.dir/build.make:66: CMakeFiles/cmTC_6a36b.dir/CheckSymbolExists.c.obj] Error 1
make[1]: Leaving directory ā€˜/home/BrianP/src/MINGW-packages/mingw-w64-kicad-git/src/build-i686-w64-mingw32/CMakeFiles/CMakeTmpā€™
make: *** [Makefile:126: cmTC_6a36b/fast] Error 2

File C:/msys64/home/BrianP/src/MINGW-packages/mingw-w64-kicad-git/src/build-i686-w64-mingw32/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
/* */
#include <stdio.h>

int main(int argc, char** argv)
{
(void)argv;
#ifndef getc_unlocked
return ((int*)(&getc_unlocked))[argc];
#else
(void)argc;
return 0;
#endif
}

I donā€™t know what to do now.

Sorry youā€™re having such trouble with this! If I have time, I will try doing a build on a Windows VM sometime this week and let you know if I succeed, and if so, what my steps were.

Thanks! I posted an updated bug report with the build errors.

My interest in doing this is to try (despite my ignorance of c++) to make a version of PCBNew with my renumbering/back annotation function built in.

Obviously if I canā€™t build Kicad I canā€™t work on the code.

Not related to the topic, but for your information, I found this: https://github.com/hyOzd/kicad-python/blob/master/examples/pcbannotate.py

I looked at your code and it seems to handle many different situations, which this script doesnā€™t, but still the difference in LOC count shows why high level languages are nowadays preferred for high level tasks. And I agree with @mmccoo that thereā€™s much stuff in the KiCad C++ codebase which could and should be moved to python if KiCadā€™s python API and ecosystem were up to the task.

Thatā€™s certainly a path worth exploring, but reading the post by eelik above, raises a point.
Have you looked at moving your algorithms to python - that avoids ā€˜canā€™t compileā€™ issues, and also avoids ā€˜version divergenceā€™ whereby your PCBNew fork will diverge from the main releasesā€¦
There seem to be a few PCBnew variants in the wild, with nice ideas in them, but sadly not part of the main efforts.

If the python API lacks some features, is it easier to add those (which would be widely useful) ?

I have considered learning python but the only reason to do so would be for this particular application.

I use c and interface with c++ code when necessary for the things I tinker in (typically microcontroller based). It would have much more value to me to learn c++ than to learn python.

Iā€™m going to continue the conversation over on your launchpad bug report since Wayne is watching there and not here (I think)

He replied there today I believe. It seems heā€™s going to look at it. Thanks again.

This might help you:
FOSDEM 2017 - Diving into the KiCad source code

YouTube - KiCad FOSDEM 2017: Diving into the KiCad source code

Next part is a bit OT

I come(came) from similar background. Programming microcontrollers in C. But sooner or later you are going to have to connect with PC. This is where Python makes it easy. Iā€™ve tried this a couple of times using C# and Java and given up, but the third time Iā€™ve tried with Python and it was a breeze. C# and Java enforce OOP paradigm, while in Python you can start procedurally the way that you write C code and then slowly start using more and more of OO stuff.

Once I was familiar with Python I could even write KiCad pcbnew action plugin.

TL; DR; You should at least consider Python. Take a look at the code of some action plugin implementations

Hi everyone,

I just saw this question in the forum digestā€¦ Anyone still having problems building from sources on Windows 10? I am using kicad-winbuilder and it needs just a little bit love and attention to get past the error shown above. For anyone still looking for instructions, here is a step-by-step guide:

  1. Download and install CMake for Windows x64 from the official web page (mine is installed in C:\Program Files\CMake)

  2. Get the latest kicad-winbuilder master zip from GitHub

  3. Unpack and rename/move to C:\building.
    When I first started playing around with kicad-winbuilder when the official windows build server for the nightly releases was on the fritz, there was something hardcoded in the make files, which resulted in linking problems later in the build and I was unable to figure out what caused it. A build succeeded only if this is the top folder location for all of the following work. I have not checked recently, if this has been fixed or not. Feel free to skip step 3) and try putting the unpacked winbuilder somewhere else, under another nameā€¦ You might have success.

  4. Open a Windows Command Prompt and navigate to C:\building

  5. Add CMake to the CMD path. (execute set PATH=%PATH%;C:\Program Files\CMake\bin)
    This is a temporary action, will need to be repeated every time you close this windows and open a new CMD prompt. In this instance, do NOT use any quotes when you have a folder with a space in the name!

  6. Execute the batch script make_x86_64.bat
    You could also start with make_all.bat, which will build both 32 and 64 bit versions of KiCad. But I doubt you would ever use the 32-bit version, so you donā€™t really need to waste time in building that.
    The script will commence downloading and executing all kinds of crap, stating with MSYS2.
    At some point it will try to update all MSYS2 packages and crap out. At this point you might try to rerun the CMD batch script, but that is a mistake. It will only break MSYS2, because there are conflicting packages, and the update process needs to restart several times because of critical updates. What you need to do is (do not close the CMD window before the next step - if you do, you will have to repeat steps 4-6):

  7. Navigate to C:\building\msys64 in Windows Explorer

  8. Execute (double-click) msys2.exe.
    This will open a new prompt window, where you will update the MSYS2 system manually.

  9. Execute: pacman -Sy

  10. Execute: pacman -Su
    You will get several prompts for updating system libraries and conflicts. Confirm all prompts with ā€œyā€. The conflicting packages will be uninstalled, and critical infrastructure will be updated. Close the MSYS2 window and re-open it when prompted. Then execute same commands until the whole system is up to date and there are no more suggested upgrades. (Basically, repeat steps 8-11 as many times as needed, until there is nothing more to update.)

  11. Clean up after this: pacman -Sc
    Accept all prompts here as well.

  12. Now go back to the first CMD window and restart make_x86_64.bat (or make_all.bat, if that is what you used before).
    More packages will be installed. More sources will be downloaded. More code will be compiled. You will end up with with a NSIS installer package, located in C:\building\msys64\home<username>\out\pack-x86_64. After you make a backup of it somewhere out of C:\building, you will be free to get rid of the whole directory structure, since it would be 10 GBs of stuff that will sit on your driveā€¦ unless you intend to contribute to KiCad development and will rebuild often.

Have fun!

2 Likes

Thanks, trying it now!

Small typo, missing colon ā€œset PATH=%PATH%;C:\Program Files\CMake\binā€

ISTR to recall winbuilder must be top level to keep path names short.

Thx - fixed! :wink:

In Windows 10 you are able to remove the 256 characters path limit, which is the cause of the above requirement. I donā€™t recall how to do it of top of my head, but anyone interested can Google it. But even after I removed the limit, compilation for me failed in one of the KiCad plugins, if the top folder was not C:\buildingā€¦ Who knows, it might be fixed at this point, but I am not curious enough to try it right now.

Ok, I am using Win7 and c:\kicad-winbuilder. I did build once before with c:\kicad-winbuilder-3.4, so fingers crossed.

Step 10 has a small typo as well.

Closing the msys2 window gives me a warning from Windows, then I have to do a force closeā€¦ hope that is ok. Itā€™s installing a lot of stuff, so looks ok.

Update 1:

Oh well, failed with an error

pacman --noconfirm -S git make mingw-w64-x86_64-toolchain mingw-w64-x86_64-boost mingw-w64-x86_64-cairo mingw-w64-x86_64-curl mingw-w64-x86_64-glew mingw-w64-x86_64-openssl mingw-w64-x86_64-wxPython mingw-w64-x86_64-wxWidgets mingw-w64-x86_64-cmake mingw-w64-x86_64-gcc mingw-w64-x86_64-python2 mingw-w64-x86_64-python2-pip mingw-w64-x86_64-pkg-config mingw-w64-x86_64-swig mingw-w64-x86_64-libxslt bzr git doxygen
error: failed to init transaction (unable to lock database)
error: could not lock database: File exists
if youā€™re sure a package manager is not already
running, you can remove /var/lib/pacman/db.lck

I tried deleting the db.lck lock file and re-running make_x86_64.bat, but get same error.

Update 2:
I suspect the command line is too long, so I am installing packages via msys2 console.

I more or less gave up on Kicad-winbuilder for the moment as the project people didnā€™t seem to have any interest in looking at the issue. I did get some support regarding getting the Kicad make msys2 instructions going.

I realized my goal was to be able to build pcbnew to hack it so Iā€™ve focused on that. I can indeed now build pcbnew. I might try your instructions to see if they work.

Thanks for the suggestion.

The warning for forced closing of MSYS2 is OK - I had to use the task manager to kill the process too. I did not have any problems with that.

The length of the command for installing the compiler tools should be fine too, there must be something else going on. It is a good idea to open the properties of the Windows CMD prompt and increase the line buffer size to give yourself a longer history. This way, a lot more context will be available for catching whatā€™s actually failing.

Maybe you have to open a new MSYS2 prompt and try installing just a single or a couple of these packages manually. If that succeeds, do a few more, until all in the list are updated. Thatā€™s how I got past any errors in installing or updating MSYS2. Just look at what the CMake scripts were doing before any error occurred, and try to redo the same step manually, in smaller chunks.