At work I recently ran across an interesting, and the same time kind of scary situation. It's Microchip's XC32 compiler, which is based on the GPL-ed GCC, but the same time in the IDE, it shows that it's optimizations are disabled: to enable them, one is supposed to buy the Pro version. What?! It is a God-damned GPLed software, or at least to conform with GPL, it must be! So let's see, either compile it from source, or let FSF and the lawyers solve it...

Updates as of March, 2015

Since this is by far the most popular article on my site, I decided to tidy it up somewhat. First things first, how to get this (that is, an XC32 which optimizes) in the easiest way.

The quick answer for older versions of the compiler given by George (see down in the comments) is to simply replace the xclm.exe executable in your install with a dummy one roughly having the following code:

int main(){
    return 2;

The situation behind this is that the compiler (GCC, under GPL license, so it's source is all open by the requirements of this license) runs this program to acquire what kind of Microchip license it has. The constant '2' corresponds to the PRO license enabling all optimizations.

Newer gcc versions (I didn't check myself which version introduced it) introduce a simple SHA-256 check on the xclm binary. As reported by Ukoda down in the comments, it is however perfectly possible to extract the SHA-256 string from the source code, and using a hex editor on the binary, you can find it, and patch with the hash you need: just calculate the SHA-256 of the above dummy binary, and stuff that in the original's place, and it will work.

In Version 1.34, the check is called in gcc/gcc/config/pic32/mchp.c, and the SHA-256 algorithms are in gcc/gcc/config/mchp-cci/mchp_sha.h. The hash of the Microchip xclm.exe binary may also be observed here, and that it is simply stored as a string. In the installed Microchip XC32 compiler, the hash can be found in bin/bin/gcc/pic32mx/4.5.2/cc1.exe, bin/bin/gcc/pic32mx/4.5.2/cc1plus.exe and bin/bin/gcc/pic32mx/4.5.2/lto1.exe. Replacing those should make the compiler accepting the dummy xclm binary. An online SHA-256 calculator which gives the proper hashes may be found here:

There may be legal problems regarding this, however. If you only have the Microchip GCC compiler, since by the definition of GPL, you can do whatever you want with it (as long as you release any modifications to the compiler's code under the same GPL license), you can do that above, and be happy about it. However if the thing is sitting within a larger Microchip software distribution, the license of the whole may constrain what you can do to the xclm.exe executable (which is also part of other proprietary Microchip software). If you want to have the whole bundle (that is, you want to use their IDE), this applies.

To get around this (have the IDE and compile with optimizations legally, without paying Microchip a penny) you will need to alter the compiler's source to disable it looking for the Microchip license. Following this process is described as I did it about more than a year ago on a then-current version of the compiler.

The environment, the situation

The problem was a runaway project, not mine, just one I heard having problems, so checked out. It turned out they decided to use PIC32s with the Microchip IDE for development, having the 1.21 version of the XC32 compiler. Work was stalled partly for that the used micro's flash was almost full. So the situation is set. Here we have an IDE which we have to keep, and the XC32 compiler which has a GPL license slapped on it (as it must have by the definition of GPL), yet it still refuses to optimize.

So to fix it, for one, the XC32 compiler needs to be compiled for Windows as host, and for another, before compiling it, if necessary, whatever means of disabling optimizations it has must be removed (turned out it was necessary).

Let's (try to) compile XC32

First let's get the XC32 source from Microchip's software archives. I got the 1.21 version, the followings so apply primarily to that. From Microchip, you will also need (I am not entirely sure if it actually helps a lot or not, see further down why) their standard libraries, that 1.5Gb of stuff which came with the IDE (find a pic32mx folder in it with subdirectories like bin, lib, include, from this, take lib and include), I just picked up these from the IDE (which of course was also using the 1.21 compiler) already installed.

Now that beast is a GCC source, one which needs to be built with Autotools. This won't quite work on Windows, so enters Cygwin. Get it's setup, it is quite small since it will download it's bulk during installation. It contains a nice package manager where you can select the components you need. To do this compiling job, these are gcc, make, binutils, automake, autoconf, bison, flex, and iconv. Maybe some more, but you will figure it out. Luckily the installer can always be reran to add more packages, even while a Cygwin shell is running (tip: you may also want to install "mc": the Midnight Commander, it can help a lot).

Note that in Cygwin you can access your disks as they are through the path /cygdrive.

Extract the XC32 source archive to some convenient place for the build. Preferably not too deep since you may need to specify paths to components in it. The source archive has some folders within: the various components of the compiler which you need to compile in the correct order with the correct flags to make it work. Create a [componentname]_build directory (like gcc_build) for each except zlib (this can't compile out of it's source tree), these will be where you build the packages.

You also need a place where the compiler and it's components will be installed for now. This is preferably should look like [somepath]/usr, later I will refer to this "somepath" as "installpath".

Now do two exports to allow the components installed finding each other:

export CPPFLAGS="-I[installpath]/usr/include"
export LDFLAGS="-L[installpath]/usr/lib"

The first will allow the (native) compiler to find the headers of the components installed, the second allows the (native) linker to find the libraries.

Preparations are done with this, you can now build each component one after each other (note: build each in their respective build directories you created before except zlib, which is to be built in it's source directory). It is basically configure - make - make install, you just need to keep the proper order and supply the proper arguments. In general I aimed to do everything static: I didn't want to mess with shared libraries especially considering this is Windows, and I will also need to pick out the compiler executable later.


../gmp/configure --prefix=[installpath]/usr --disable-shared --enable-static --enable-cxx

The --enable-cxx is for building the C++ interface which will be needed by ppl.


../ppl/configure --prefix=[installpath]/usr --disable-shared --enable-static


../cloog/configure --prefix=[installpath]/usr --disable-shared --enable-static --with-ppl=[installpath]/usr

The --with-ppl is needed since it will try to build itself without it otherwise and fail.


../libelf/configure --prefix=[installpath]/usr --disable-shared

This does not recognize the --enable-static option, but of course will build a proper static library for us.

zlib (note: build within it's source):

./configure --prefix=[installpath]/usr


../binutils/configure --prefix=[installpath]/usr --disable-shared --enable-static --target=pic32mx --with-dwarf2

The --with-dwarf2 option makes sure it builds supporting Dwarf2 debugging model which is also used for C++ exception handling.

copy the Microchip libraries

Unless you did it before, this is the last time when you may copy the Microchip C/C++ libraries into your install directory to let GCC building it's own standard C/C++ libraries. Copy them into [installpath]/usr/pic32mx which is already created for you by binutils' install script (you will so have an include and a lib directory added here with all that 1.5Gbytes of stuff).

You will also need to patch the GCC source to disable the license checking, see in the next chapter.


../configure --prefix=[installpath]/usr --disable-shared --enable-static --target=pic32mx --enable-languages=c,c++,lto --disable-objc-gc --enable-lto --with-host-libstdcxx=-lstdc++ --enable-multilib --with-dwarf2 --disable-sjlj-exceptions --with-sysroot=[installpath]/usr/pic32mx

The --enable-languages option selects you the languages to build. Since Microchip only supports C and C++, only build these. lto enables link time optimization, maybe --enable-lto is redundant for this.

The --disable-objc-gc option is maybe unnecessary as we don't build objective C. This would disable building the garbage collector for it. I just left it in to make sure.

The --with-host-libstdcxx=-lstdc++ is needed to properly link gcc with the previously compiled ppl package. otherwise it won't find the c++ libraries.

The --enable-multilib option is maybe also unnecessary as this might be the default, just make sure.

The --with-dwarf2 and the --disable-sjlj-exceptions are both necessary so the compilation properly sets and detects the exception model to use. For more on this, maybe

Hanna Code (link) error: ID is not numeric
. If you miss the latter, the compilation will abort with a nasty "unable to detect exception model" error.

The --with-sysroot option tells the build system where it can find the target libraries so it can build it's own. If you fail to set this, you will get a "Link tests are not allowed after GCC_NO_EXECUTABLES" error.

If you are lucky running this, you will get the compiler done, and it will get quite far into compiling it's standard libraries for the target, but will eventually fail. The failure which happened to hit me is that within the Microchip libraries (!, that 1.5Gig stuff you copied in from the IDE) in a header (sys/posix.h) there is a reference to unistd.h at a not even existing path!

This left me somewhat confused. How Microchip was supposed to build this if it fails on their own library? Anyway I patched this problem (there is an unistd.h within there which I used for the purpose), but the compile still failed later, now again with a "Link tests are not allowed after GCC_NO_EXECUTABLES" error.

I stopped at this point: for one, it already compiled the compiler, for two, it already took more than a hour on a four core machine to get to the error.

Experiences with the result? See some chapters below!

Bye-bye, license check

So how to fulfil our original purpose and make the compiler actually optimizing?

The clue lies in the messages it barfs out telling you to register it. It is a nice string to search for, so basically I did a

grep -r "compiler license" ./

on the gcc source directory. For this version I got this finding two sources, one in gcc/config/pic30, the other in gcc/config/pic32. Then I did search the (huge!!! the saying about manageable module size was really some 500, but LINES, not KILOBYTES, dammit!) source files for the string. Currently the problem is easily fixable: you will see there is a nice variable with a long name there holding which license you have, and with some search you will also get the constants to use on it. The simplest thing is to just slap the constant for the PRO license in each occurrence of assignments to this variable in both source files (replacing any FREE license constants, -1 or zero).

Compile, and smile: it works and optimizes happily!

Experiences with the result, how to actually use it

When you get the compiler binary, you may need to take it away and maybe use it with the IDE. But since this was a Cygwin compile for a Cygwin host, no matter that the resulting gcc is a bloated monster (having everything static compiled within), it still needs some Cygwin dll's. To find out which, you can do cygcheck cc1.exe and so on on all the necessary executables. This will tell which dll's they use, so you can copy them off the Cygwin installation to a place where the binaries can find them without running the exe's from within Cygwin (dropping them next to the binary works).

It is not ideal, but at us so far only cc1.exe was replaced (old non-optimizing cc1.exe was archived, just in case) within the Microchip IDE, and it seems to work all right for C programs (the project does not use C++, so we didn't try that).

Probably later we will experiment some more, but for now it works, solved the immediate problem (binary barely fitting in the PIC32 micro). At least this is a proof of concept that it is indeed doable.

Some words on GPL, and why this is scary

The General Public License's intentions are to (if necessary, forcibly) keep software being publicly accessible and develop-able, to disallow taking someone's work and to lock it up probably even slapping some software patents on it with a probable intention of "hijacking" it. A GPL-ed software is free, end of story.

GPL technically forces people to at least publish the source of their work with the allowance of doing whatever one wants with it (as long as the resulting work is kept released under GPL).

In Microchip's case, it is technically true. There is a source, it is compilable, and apparently it gives the compiler all fine. So technically, by the words of law, they did not violate GPL with this thing.

The problem is there that GPL does not state (or not clearly enough) that one also needs to provide the informations necessary to actually build the software. If I go far with this, I may well end up developing a software from a GPL-ed one for which, inside the company, we have, say, an A/4 sized build instructions list with a good set of arcane flags, switches, maybe even codes. The source is there, now go, compile it. You can't? That's not our problem.

(The Microchip source has some main build script, but partly seems to be completely unrelated building several other packages: to actually build this thing, one has to figure it all on his own wading through the Internet for days)

So although Microchip does not actually violate GPL here, I really think it goes against it's intentions. They can since the PIC32 is not a so common architecture that anyone will pick their compiler up, and keep up with them releasing "proper" truly GPL conforming sources and maybe binaries.

Well, if anything else, I would be interested to hear your opinions, be it related to GPL or if you found something out about the compilation process itself!



  • Created: 22 May 2020, 2:43pm

This is awesome. Confirmed to work on v2.40. Used Frhed as recommended by others including And_And. My dummy exe only returns a 2, that's all it does. And make sure you're patching cc1.exe, not xc32-cc1.exe (you won't find the hash in that one anyway).


  • Created: 3 Mar 2020, 8:56pm

Version 2.40 can be worked with the SHA-256 hack.Tested with an example project on O3 optimizations.xclm made with Visual Studio.
Used Frhed and the sha256 site.


  • Created: 3 Aug 2019, 11:33am

CodeRunner: I would say, just use the SHA key hack described on the top of the article, at least I hope it may still apply. You may get the xclm.exe's hash using the tool mentioned there, search for that in the files mentioned in the article, and try replacing them to the hash of the dummy. It might just work.

(Wow, I wouldn't have thought I would ever get this many comments on a single article during the years. I will need to do something about the site to get this all less unwieldy)


  • Created: 25 Jul 2019, 9:58am

Hi, method about Image File Execution options Debugger key seems not working here with Win10 64bit, XC8 v1.41, MPLABX v4.15 (return code used 6 compiled with MinGW gcc tdm64-1 5.1.0), the output from the compiler tell about compilation was made in Free mode although tha settings of the optimization was set to PRO... some advice? Thank!!


  • Created: 28 Jun 2019, 6:09am

Unfortunately Skydev, using the IFEO method, the compilation didn't work and threw up "createProcess" errors.


  • Created: 20 Apr 2019, 5:20pm

G._Braguti: Maybe you need to turn on optimization in project settings and clean-then-rebuild. If you turn on optimization without valid license you will see errors (red lines) in output. If you do not clean before rebuilding compiler will not be reinvoked at all.


  • Created: 20 Apr 2019, 5:18pm

It is actually MUCH easier than that. You do not need to touch any files, just some system settings. Simply create the return 2 executable and override the xclm.exe using Image File Execution options Debugger key. For example, if you put that executable as C:\StaticReturn2.exe, you would need to add to your registry:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\xclm.exe]

And voila! Everything works! SHA check is passed because executable is untouched, but the system itself launches StaticReturn2 instead of xclm.exe and passes the return 2 to the caller!

Even more, this will automatically work for all compilers - xc8, xc16 and xc32! Windows magic!


  • Created: 1 Apr 2019, 8:26pm

G._Braguti: Maybe you could try with a return value of 2. Commenter "ideras" below suggests that he saw the change to 6 in version 1.42, so yours might still expect 2. Otherwise sorry, no much idea, I didn't use Microchip compilers since I originally made the article.


  • Created: 20 Mar 2019, 4:29pm

Good morning all,
I try this trick on my MPLAB X v.5.15 and XC32 v.1.40 but I fail (nothing change compiling my project)...
This my procedure:
I create a new xclm.exe:
with Dev-C++ tool I create a project for "Console apllication" with these source lines:
int main(void)
printf ("Checkig XC32OVERRIDE");
return 6;
Compiling it I obtain an exe file of 131.002 bytes that I rename "xclm.exe".

I find the SHA-256 of original xclm.exe (2e162eef9b84179f6b5a6d3bcc3e8bfe603079c7daa70251297de54b07009fa3).

I find the SHA-256 of the new xclm.exe (60fb08f2516d3ae2bab66b7cfd4ec1121e37243ce9b70ca8e842aef825cf6ced).

I sobstitute the xclm.exe in directory \bin (where I found the original version) with new one.

I seek the files cc1.exe, cc1plus.exe and lto1.exe and I find them in \bin\bin\gcc\pic32mx\4.8.3
I seek the SHA-256 text of original xclm.exe in cc1.exe (I found it at line 73158C) and replace with new SHA-256.
The same in cc1plus.exe (at line 7FCF20) and lto1.exe at line 6DB080).
Open MPLAB X and compiling my project, I have the same code dimension (not optimized).

Many thanks at all would like help me.
G. Braguti


  • Created: 28 Oct 2018, 5:33pm


Just a quick update: the trick still works with v2.10.


  • Created: 31 Dec 2017, 6:05pm

In case anyone has problems finding the SHA-256 hash values in the binaries, they are stored as text strings, not hex values.


  • Created: 31 Dec 2017, 4:29pm

In case anyone has problems finding the SHA-256 hash values in the binaries, they are stored as text strings, not hex values.


  • Created: 8 Nov 2017, 7:06pm

Thank you for the prompt reply. I was unclear, I was trying to do the same thing but I couldnt find the hash value from mchp_sha.h or the one I calculated in the executables. But I was looking in the wrong files. Your excellent guide clear says which files it is but I was looking in bin/xc32-cc1.exe

Thank you very much for writing and sharing this guide!


  • Created: 7 Nov 2017, 6:15pm

mkmay: He refers to an alternate method where he patches the binaries themselves (so he does not actually compile gcc). You can see it in the middle of the "Updates as of March, 2015" section, that also works.


  • Created: 6 Nov 2017, 12:38pm

b1ade68: how do you mean it is encoded?

in mchp.c around line 1100 is the code that performs the validationn. As far as I can see there is no encoding or obfuscation.


  • Created: 30 Sep 2017, 3:57am

I believe Microchip is in violation of the provision that:
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable.
The "Corresponding Source" for a work in object code form means all
the source code needed to generate, install, and (for an executable
work) run the object code and to modify the work, including scripts to
control those activities.

Last time I tried building their compiler, they did not have scripts that would allow you to build the exact exe's they provided.


  • Created: 19 Aug 2017, 12:33pm

Finally i did it. The problem was SHA-256 hash is encoded in files cc1, lto1 and cc1plus so you need a good hex editor/viewer.


  • Created: 19 Aug 2017, 10:05am

Wes thank you for the response. I'm using MPLab for build a real project, so surely I compiled something before searching SHA256 hash. I will do all operations another time with more attention.


  • Created: 12 Aug 2017, 3:43pm

blade68, I believe you have to use MPLab to compile something first.

After I built a program, I calculated the SHA256 hash of xclm.exe and I was able to find that hash in cc1.exe, cc1plus.exe, and lto1.exe using a hex editor.


  • Created: 30 Jul 2017, 12:06pm

Hello, I tried to enable optimization in xc32 1.44 without success. I understand, reading flo comments, that SHA-256 reference string used can be different with the one present in gcc/gcc/config/mchp-cci/mchp_sha.h, but however this string should be the SHA-256 hash of the file xclm.exe (or not?). In my windows installation I calculate SHA-256 hash of xclm.exe but I cannot find that hash in cc1, cc1plus and lto1. Has anybody activate licence on xc32 1.44 on windows? Thank you for the great post.


  • Created: 20 Jul 2017, 4:57pm

Hello again,

all of the sudden I wanted to check the building flags xc32 was compiled with and ran ./bin/xc32-g++ -v.

Suddenly there appeared a SHA-256 string which differs from the ones in the gcc/gcc/config/mchp-cci/mchp_sha.h of the sources. I could finally find this string in the above mentioned binaries cc1, cc1plus and lto1 in bin/bin/gcc/pic32mx/4.8.3/. Changed it to the one of my xclm which returns 6 from the main function and voila, looks like optimization is working.

Thank you very much for the initial article and the comments!


  • Created: 19 Jul 2017, 11:20pm


I tried to unlock the optimization for v1.44 through the dummy xclm.

In the sources I could find the SHA-256 value for the xclm file in gcc/gcc/config/mchp-cci/mchp_sha.h. But afterwards I could not find neither of the three (Win, Linux, OS X) SHA-256 strings, or substrings of them, in the above mentioned binaries. I searched for it with an OS X app called "iHex" and with "strings" in the terminal, both methods didn't hit anything.

I'am curious if they changed the validation of the xclm or if i'am doing something completely wrong. A comment below states that it is still working with v1.42...


  • Created: 13 Apr 2017, 4:16am

Here is the code I use. It allows override of the return via an environmental variable


int main (void)
int Ret = 2;

char* Swap;
char* pEnd;
printf ("Checkig XC32OVERRIDE");
Swap = getenv ("XC32OVERRIDE");
if (Swap!=NULL)
Ret = strtol(Swap, &pEnd, 10);

return Ret;


  • Created: 26 Jun 2016, 6:35pm

In version 1.42 (at least) the value returned by the main function should 6, not 2. So the function should be as follow:

int main(){
return 6;


  • Created: 25 Dec 2015, 3:44pm

This works also for XC32 1.40. Thanks!


  • Created: 23 Dec 2015, 7:21am


I am following your directions, trying to recompile the latest 1.4 xc30 compiler. However, I get an error at the PPL stage: f_info(const T&, bool open) {
make[6]: *** [ppl_c_Rational_Box.lo] Error 1

In looking on google, I tried adding -fpermissive to the compiler flags, and it got further along, but still bonked with the same error.

I'm on Ubuntu 14.04. Any idea what I'm doing wrong? Are there other options? Perhaps a pre-patched xc32 and xc16 that can be downloaded w/out the license check?

Thank you! Your guide is great!


  • Created: 5 Dec 2015, 11:26am

To make the usefulness of all that stuff clear: You can compile the XC16 and XC32 for yourself. The XC8 is a different compiler.
I am currently building the XC32 v1.40 with MinGW. This allows you to forget about all those Cygwin-DLLs.
And another tip: for config-options of the gcc itself, you can check out what microchip used: "xc32-gcc -v" prints out all that stuff (which will need some changes - at least for pathes).


  • Created: 24 Nov 2015, 5:26pm


Replacing the xclm.exe by a "return 2" binary is perfectly legal. We do not alter Microchip's copyrighted program (xclm), we delete it. If it's the name you don't like, I am sure we can patch the gcc binaries (GPLed, so legal) so that they look for another file name than xclm.exe.

thanks for the trick!


  • Created: 14 Nov 2015, 6:09am

Hi guys, Thanks for this useful article. I had the same problem and was looking for a simple solution. I'm a hobbyist with a really limited budget. First I installed MPLAB and the compiler every two months on a different machine. But one day I had no more unused equipment left. Later I tried to write my own xclm script. Unfortunately it didn't work (SHA-1 test). Well, I found a really simple solution: I'm using a Unix system (Mac OS X) and discovered that the xclm hostid is identical to the en0 ether address (Primary Ethernet MAC). It's easy to temporarily change the primary network MAC on a Unix / Linux system. You only have to run the following command: $ sudo ifconfig en0 ether xx:xx:xx:xx:xx:xx where xxxxxxxxxxxx corresponds to any arbitrary host ID. Now you can download a new demo license with this fictitious ID from Microchip. Install it, and your compiler will work for two more months in PRO mode. I used the same microchip account several times without any issues.


  • Created: 20 Oct 2015, 7:33am

Beating the Devil at his own game, This works for the 18c, and the 30c and am checking it out for the xc32
simply make a basic virtual machine with xp and nothing else, make a copy of it to another directory for the reload, then set up the microchip stuff when the 60 day trial runs out, reload the virtual machine to another directory and reinstall Wala another 60 day trial, erase the old virtual file, and now to the 32 bit stuff, i will use another email addy and then change the mac address, it should work fine


  • Created: 14 Sep 2015, 7:27pm

Strike that last; I don't think MIPS cores are sold/licenced by ARM or vice versa. Too much coffee/not enough ... zzzz.


  • Created: 14 Sep 2015, 7:20pm

I do tinker with Atmel stuff and will likely embrace it more. But PIC is, despite the spawn of ******* who manage the company, easy kit and well designed. There may be a ray of hope in sdcc which is promising more comprehensive coverage.

Of course what we really need is a wealthy VC (who wasn't around when his parents got married) and would help pay for ARM core licenses to build proper 32-bit MIPS MCUs from the FSF-ground up.

I'm looking ints Atmel as an alternative. The nice thing is that the ARM cores are licensable and it's really pennies to a wealthy ex-Chief Architect of some now-marginalised over-capitalised under-ip-resourced pirate of other people's ideas.

Surely an obscenely wealthy human being would take up the chance to allow the IOT to be truly participated in by the very people it will ultimately milk for profit?

Or has farming become a thing of the past ...


  • Created: 14 Sep 2015, 6:36pm

Hope you could get it working then!

I mailed you a third method of getting this going, if you didn't feel up to either. For the legality as long as you only mess with the GCC part, it should be in the green by the power of GPL (if anyone says otherwise, we can still knock on FSF's door for some help, likely there are a "few" people not quite pleased with how someone is abusing their work... GPL *IS* a license, giving us a product not for money, but for the requirement of contribution, so essentially Microchip here simply decided to not "pay" for a service they "purchased").

Why Microchip is doing this? Likely they save a few cents on parts by this, which makes their IC's a bit more appealing for large firms ordering those by the hundred thousands (where the gain on IC purchases offset the cost of the compiler). Atmel on the other hand gives away their compilers for free, likely spreading the development costs over their part prices, which is better for the hobbyist and small firms working with batches of a few hundreds or thousands.

Microchip certainly abuses GCC by this practice, but for other products (such as XC8 or XC16), I would say, vote by foot, don't whine. Buy an Arduino for your hobbyist gear ;)


  • Created: 12 Sep 2015, 11:33am

Thanks for this article.

I'm a hobbyist, I can't afford (nor would pay if I could I suspect) the PRO license since this amounts to extortion when applied to a GPL product.

They currently allow a 60-day PRO evaluation and the host id appears to be the MAC address of the primary ethernet card. (I don't know what it would be if there isn't a network card installed). That might be a starting point to get a fair go.

I've tried to get around licensing it by using a mips-none-elf-gcc cross-compiler as a post-build step to replace the previously generated .o files that I want to properly optimised. The problem is that the object file output doesn't link (File format error) with xc32-ld or xc32-gcc.

I don't see how unlocking something that is meant to be freely available is in any way a crime. Only attempting to profit from it by reselling it perhaps.

Microchip surely do very well from fab sales, I fail to see why they won't make the PRO compiler free. Yes, I can. Greed.

Also I've used the MPLABX IDE for a few months and I'm not impressed. (PICKit3 has many problems not least inherent flakiness) The whole thing is overcomplicated and it runs under Java so a huge VM (5.2GB right now) is created to run code that would compile to - at most - a few tens of megs of native code.

Command-line tools as an option? Nope.

I hope the fight continues.


  • Created: 16 Apr 2015, 10:15pm

*Kilo*: I didn't try, and no-one reported back experiences on those. It might work. Note that however that doing this with those compilers is *illegal*! I am keeping this post since in the case of GCC, Microchip even if by the legal of GPL is doing something acceptable, it doesn't follow the ethic behind the license, it's intentions. They are violating on this term (even though as far as the legalese goes, they don't), and this post contains nothing illegal by itself or any promotion of any illegal activity, just something permitted by GPL itself. If they were following GPL's intentions, this whole post would be moot. Until then it hopefully can serve as a tool to make you receive your rights GCC's license should be providing the first place.


  • Created: 12 Apr 2015, 8:03pm

Will this process also work for the XC8 and XC16 compilers as well?


  • Created: 10 Oct 2014, 9:37am

Wow! So the spirit is on, we keep merrily "optimizing" (our codes and costs), no matter what Microchip is up to!

The standpoint of your employer is understandable, such a movement I talked about is only viable initiated from independent sources. The PIC32 maybe has just too small user base, probably mostly lacking hobbyists. Maybe partly especially for Microchip's decision: Around AVR the same time there is a thriving community, just look at the Arduino, but it's not hard to pick up a dozen of others either. They offer their compilers for free (both for 8 bits and 32 bits), which might have been a deciding factor.


  • Created: 10 Oct 2014, 12:30am

My employer will likely use about 10K chips which is small business for Microchip but still get us their ear. I raised the issue of selling GPL code with them and was offered a significant discount on a license purchase. The idea of releasing uncrippled version is tempting but my employer still needs the goodwill of Microchip so a bit worried about upsetting them and the potential effect on my employment status. It may be better done by a hobbyist than an employee.

As for your second suggestion, the same idea had occurred to me so I was already playing with such ideas. I can report that patching the sha-256 strings in cc1.exe and cc1plus.exe allows the George hack to work again.


  • Created: 9 Oct 2014, 6:36pm

*Ukoda*: I don't think so. As you can read here (and as you experienced), even compiling this is not something trivial. People having interest in the 32 bit PIC should pick this project up, since gcc is GPL'ed, it is completely legal to do so. One knowing how to work with gcc's source could follow Microchip's changes in a free variant (using some diff tool this alone is not hard), and keep up updating compiled binaries.

This certainly won't be me, though, I am happy to be out of this mess. I guess, likewise, my co-workers are also happy that it is done for good. It was just some USB crap to be done somehow at last after a gigantic screw-up with some disaster called Vinculum, and no-one even cared to look at PIC32 ever since.

*An alternate way to deal with this* may be if you find the hash value gcc compares to in it's (I mean gcc's) binary, and using a hex editor, simply change it to the dummy's hash. You can check in the source code of gcc whether the hash value itself is guarded in any manner. Of course tampering with the binary could give many other opportunities to by-pass the license check, but this should be the simplest to accomplish.


  • Created: 9 Oct 2014, 5:38am

George's trick no longer works as they now do a sha256 check on xclm. I'm not having much luck with building the compiler from scratch, so far. I wonder if anyone has posted a valid fixed GPL build version online somewhere that can be downloaded?


  • Created: 2 Sep 2014, 9:28pm

From the reading of XC16 source and running of xclm, I understand that XC License Manager is not a part of XC compilers source but proprietary, Microchip copyright. In the case of XC16, the search for `xclm` path is coded in the source of the compiler (nothing related to MPLAB). The compiler, xc16 binary, will execute, for example on Windows, `xclm.exe -fcfc swxc16 1.21 02-09-2014`. The exit status, echo %errorlevel%, is an integer that gives the license validity: 0 for no or free license, 1 for standard, 2 for pro.


  • Created: 10 Jun 2014, 10:39pm

I replaced the xclm.exe on my XC32 v1.31 like George suggested and it works great! Suddenly I get the "pro" version just fine!


  • Created: 19 Feb 2014, 5:59pm

*Nicolas*: this is probably just like what *George* suggested, the problem is that if you use Microchip's IDE, the GCC package will look for *xclm* in a path under Microchip's "domain". If I don't mis-understand you don't even need to do anything fancy, just take a look at *George*'s solution below. The problem with that is that by replacing *xclm* in a full-fledged IDE indtallation, you might violate Microchip's license covering this non-GPL portion. If you use the compiler stand-alone, you can do anything including what *George* did, Microchip has no base for complaining then.

An other way to defeat this might be finding out how GCC actually looks for the *xclm* executable. There might be a way to fool the compiler installed within the IDE (without recompiling) to look elsewhere, and then you would be able to stun it with a dummy *xclm* legally, happily using the IDE and having it optimizing the same time.

Eh, and I guess I misunderstood a bit after all. You seeked out for "cracking" the license check based on the assumption you will find it's code within the GPL'ed GCC source. This is not the case as you can see above, and pretty clear in *George*'s solution.


  • Created: 16 Feb 2014, 12:18pm

I guess the code to check the license is present in the downloaded sources. Has anybody tried to look at it to generate license strings so that you don't have to re-compile xc32 for each new release ?


  • Created: 28 Jan 2014, 6:39pm

Thanks Jubatian, George!
This trick with xclm works perfectly with 1.31 compiler.

Modifications are explicitly forbidden in the license, but russian federal law allows them for personal(and not-so) use.


  • Created: 25 Jan 2014, 5:44pm

Nice to hear my post was of use!

A little additional on licensing: Although below I found it nifty how *George* worked around the problem, it might not be the best thing to do if you want to stay in the clear, I mean legally. That *xclm* binary may be covered by Microchip's own proprietary license (did not check), so it might be a violation even to replace it inside the Microchip provided tree. Of course there are workarounds (like if you only have gcc, and interpreting it's source you set up a suitable dummy *xclm* on your own: of course then you won't have the IDE), but where it matters you should probably carefully check the legal state of your hack.


  • Created: 23 Jan 2014, 3:37am


Thank you so much for writing this. It gave me some OOmph to go and roll my own. I followed everything but the configure flags that I found on MCHP's forums. I was going to try 1.31 but I ended up with 1.21 as it supports my needs. I'm compiling this for armv7l not x86 and ran into the same make errors you did(but cc1 & xgcc were built). As for the licence I found ./pic32/mchp.c in gcc and it handily has a define to skip checking in the function "`pic32_get_license`" this also just returns 2 when defined (well adds it to a variable). I've checked the code running on hardware *thumbs up*

To note: I built this on my nexus7 and gcc only took 10 mins! bloody thing untars files faster than my pc too.

I can now compile xc32 stuff on the move with android. Maybe a first? One of many never documented. *sigh* is it time to start blogging?!. Now to write a bootloader application for android native.

Thanks again.


  • Created: 20 Nov 2013, 6:27pm

Huh, nice! I re-downloaded that beast of XC32 source to check it out somewhat: it seems like it might work there too. The license check part seems to just call *xclm* on some path, and use it's return value. The constant for the PRO license (`MCHP_XCLM_VALID_PRO_LICENSE`) is actually 2 there too, so by this this stub copied at the appropriate place should do it. At least unless something else checks if it is a valid *xclm* executable. I did not try it (didn't want to install that mess of IDE here at home on my Linux rig just to check). Maybe someone else actually (I mean with XC32) having this problem will check this, at least it is a lot simpler than trying to compile that beast if it works!

Eh, proves I will just never be a hacker - think out of the box?!


  • Created: 19 Nov 2013, 8:09pm

I'm actually using XC16 v1.11; your mileage might vary...

So after digging a bit in the DRM-encumbered GCC source code, I found the section which checks for a license. (It's not hard to find, just grep for LICENSE_MANAGER in the source tree.) It seems it just calls a utility called `xclm` to check for a license. I studied the code, and felt I knew enough to write a replacement, friendlier license manager:

int main()
return 2;

Compile this to an executable named `xclm` and put it in the bin/ directory of the XC16 compiler, replacing the old `xclm`. Voila, no mucking with recompiling an ancient compiler required!


  • Created: 14 Nov 2013, 4:55pm

Hi! This is already a bit old, you should probably work it through yourself on the current version using this as a guide. In such a large source file stuff might have changed since, and I neither have that compiler any more (it was done for a colleague at work). Just do what I did: first use grep to find it, then you will likely see what to do inside. It is not an #ifdef (at least my solution wasn't based on it), it is a variable indicating the license version, which gets #define'd constants for it's value. I just fished out the #define for the PRO version, and on every assignment to this variable, replaced the constant, and ho, no more license checking crap! It is an another story to wade through compiling it... (patching up that source is just at most thirty minutes, compiling that beast is what will likely take your days)


  • Created: 12 Nov 2013, 2:42am

Gorgeous. Any chance you could post the patch you used on the compiler? As I read through it, I see that all the license functionality is behind an `#ifdef` but I can't see that it's actually being `#defined` anywhere.

Make a comment


  1. Please be polite (Leave all your trolls in their respective caves).
  2. If #1 fails, don't feed 'em. They bite.
  3. No links allowed. It won't pass. Neither chains. Use '(dot)' notation.
  4. Spam reeks.
  5. Text is (some day will be) formatted with Markdown.
  6. Your mail address is only visible to me: I understand you also don't like #4.
  7. The mail address you provide is also used to fetch your Gravatar.
  8. Danger! High voltage! Right between your "Post Comment" button and ground.
  9. Still want to comment? Go ahead! :)