Build for Solaris 10?



Never used KiCad in the past, but have just installed for FreeBSD x64 and looks pretty good. Unfortunately, that solution would involves a separate machine, as the only version of windows in use here, server 2003, on one machine, isn’t supported. Prefer a unix environment in any case, but wondering if the package has been built by someone to run under Solaris 10 Sparc ?. I’m using netbeans and gnu tools under Solaris for embedded software development, so it would be more convenient to have KiCad running on that machine. If that’s not been done, just how easy would it be to build KiCad to run under Solaris 10 Sparc ?. Am familiar with package building and software dev and have built gcc cross for other architectures, but this looks very complex, loads of dependencies and wonder what the possible issues would be. Any advice, pointers etc would be appreciated…




You could look into flatpak or similar portable solutions.


Sparc is not supported and will likely never be.



Most likely issue is the assembler code for the Coroutines. I have a branch that backs out the commits that switched from Boost.Context to our own assembler code, but the Boost.Context based implementation depends on library internals and doesn’t work with every version of Boost (1.61 is known bad, 1.65 and 1.67 are known good IIRC).

Other than that, it should be fairly straightforward, but a bit tedious because of the dependencies.



Thanks for the replies. Surprising that there is any assembler left in application code these days, but why does it need that ?. Not a criticism, just curious. Last time i used coroutines in assembler was on pdp11 systems, but, for example, everything, even interrupt handlers are usually written in C these days for embedded work. Only exception would be startup code, but the idea is to get the C runtime up as early as possible as it’s easier to maintain and also for portability reasons.

Have built a FreeBSD, amd64 system over the holidays, now up and running with a few useful apps and will be getting into the learning curve for KiCad. FreeBSD is about the closest I can find to Solaris, lightweight, with ZFS and jails and of course, no systemd :-). KiCad looks like an amazing effort though and way beyond my capabilities to design and build.

With thanks, and a happy new year…




Disclaimer: I’ve been only following KiCad development relatively recently so don’t have the whole picture, core devs may provide better answer.
From what I can tell assembler code is used to implement in-thread lightweight context switching library as a replacement for boost.context after the latter was a source of grief for the devs because of unstable API and plain broken versions affecting KiCad. When you need to directly access CPU registers assembler is still best if not only tool for the job.


Thanks for that. I guess that rules out any other arch but X86, unless there is a version of the library for Sparc or perhaps Arm (more likely), or even Power. I’ll look into that, as there may be equivalents for Solaris that could perhaps be made to work using a wrapper function layer.

Anyway, started with KiCad schematic editor, a trivial voltage clamp project, over the past couple of days and it seems very intuitive. it’s years since i did any of this and i haven’t had to look at the manual once. Always a good test for how intuitive a package is to use. Vast library of up to date parts as well…




There is a patch being considered right now to implement that for Loongson MIPS64 cpu, that might be of interest to you.


ARM is also currently supported


Longson sounds Chinese ?, but of course, it depends on suitable hardware to run the os and apps. I’ve been waiting fro ages for a workstation class Arm machine, like the old Sun desktops. All the effort seems to be going towards servers, which is a larger market, though you could put a decent graphics card in to build a workstation from any suitable hardware. There’s also Risc V, which is getting more support, though that’s more embedded oriented at present.

Anything, just anything to get away from the Intel monopoly, would be great…




As I said, my branch backs that change out and uses Boost.Context instead, which should have support for a wider range of platforms.