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:
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: https://md5file.com/calculator.
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:
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
--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
--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):
../binutils/configure --prefix=[installpath]/usr --disable-shared --enable-static --target=pic32mx --with-dwarf2
--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
--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.
--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.
--with-host-libstdcxx=-lstdc++ is needed to properly link gcc with the previously compiled ppl package. otherwise it won't find the c++ libraries.
--enable-multilib option is maybe also unnecessary as this might be the default, just make sure.
--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
--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!