Building Microchip XC32 Compiler - Page 1
Forum section: electronics / general

author: PuppyEngineer
author_rank: Newbie
timestamp: April 08, 2018, 10:22:32 pm
content: Has anyone successfully built the XC32 compilers from the sources on Linux or Windows (MSYS2)?I've attempted it in order to possibly update it to a newer GCC version for C++, but I get a medley offailures. Most I've been able to subdue, but it's been a fairly frustrating process so far.All of this is to update the GCC version from 4.8.3 to something even just a little past that, asit still uses the TR1 versions of some of the headers with quirks. Stuff like <array> requiringa heap or some headers requiring RTTI. I've compared a lot of these issues with GCC 7.2 for ARM with--no-rtti and no heap and it works just fine.

author: legacy
author_rank: Super Contributor
timestamp: April 08, 2018, 10:26:31 pm
content: dunno, but you'd best look at some receipt from some distro (e.g. debian) to see which tricks need to be applied

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 09, 2018, 12:36:39 am
content: I tried a couple years ago, and gave up.Problem is, as far as I know, GCC never included the PIC32 target in the mainline source code, whereas a lot of other targets are part of it. There's probably a good reason. (Funnily enough, I managed to build GCC for the LM32 target (LatticeMico32, Lattice 32-bit soft core) without any problem.)So anyway, your chances of getting to build XC32 with any other version of GCC than the one Microchip used is close to none (and even with the right version, it's a huge pain to build). And even if it built, the probability of compiler bugs would be very high, so I wouldn't bother.

author: westfw
author_rank: Super Contributor
timestamp: April 09, 2018, 01:04:23 am
content: QuoteIt's a MIPS chip, isn't it? Some ugly string of modifiers should make a generic MIPS gcc produce usable code?

author: technix
author_rank: Super Contributor
timestamp: April 09, 2018, 03:24:24 am
content: Quote from: westfw on April 09, 2018, 01:04:23 amTechnically, yes. In reality, you would need the linker scripts from Microchip that matches the memory configuration. Otherwise it is mostly choosing the processor core and FPU.

author: andersm
author_rank: Super Contributor
timestamp: April 09, 2018, 04:46:44 am
content: You may need to disable warnings as errors when configuring. Newer compilers issue a lot of warnings for older versions of GCC (and Microchip's own additions are definitely not warning clean). Also have a look at thechipKIT build script.

author: andersm
author_rank: Super Contributor
timestamp: April 09, 2018, 05:00:34 am
content: Quote from: westfw on April 09, 2018, 01:04:23 amYes, as long as you don't need to be source or binary compatible with XC32.

author: ale500
author_rank: Frequent Contributor
timestamp: April 09, 2018, 05:21:55 am
content: The chipkit gcc, that do not have the optimization limitations produces compatible libs and objects.I also tried several times to compile it in different environments, cygwin or mingw without success. Even using the chipkit compilation script. It probably depends on a very specific compiler version... maybe disabling warnings works... I never tried again. You only need cc1...

author: legacy
author_rank: Super Contributor
timestamp: April 09, 2018, 11:14:45 am
content: Quote from: westfw on April 09, 2018, 01:04:23 amnopatches need to be applied

author: legacy
author_rank: Super Contributor
timestamp: April 09, 2018, 11:21:31 am
content: Quote from: ale500 on April 09, 2018, 05:21:55 am"cc1" translates from C to assembly. It's output is a .s file. You need "gcc" and "collect2" (as well as cpp) to fully handle linker scripts and the proper flags passed to the toolchains' item (as, ld, blablbla)."gcc" is required, unless you want to create your own wrappers, and you need to be aligned with them for the Microchip's debugger.

author: legacy
author_rank: Super Contributor
timestamp: April 09, 2018, 11:30:17 am
content: Also, sometimes, you need to patch binutils as well as gcc (and not even to force gcc to use the proper flag when it invokes an tool in the toolchain, quite rather) in order to fully support hardware differences, e.g. you can use a vanilla gcc neither for Chinese's MIPS64-le nor for Calvium's MIPS64-be, since they are both not exactly compatible from the machine-layer point of view to what is provided out of the box by GNU. In this case they are claimed to be "MIPS64", but they don't fully respect the ISA.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 09, 2018, 12:15:24 pm
content: Quote from: westfw on April 09, 2018, 01:04:23 amWell, PIC32 are based on MIPS32 cores, indeed. The PIC32MX are based on MIPS32-M4K to be exact.GCC can compile code for MIPS32-M4K targets by using a GCC where MIPS targets are enabled, with the flagCode:-march=m4kon the command line.(See:https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc/MIPS-Options.html#MIPS-Options)XC32 adds the optionCode:-mprocessor=xxxto replaceCode:-march=yyy, which enables additionnal support for the specifics of PIC32, which you won't have with a plain GCC targeting MIPS.You wouldn't be able to use the Microchip support header files nor any Microchip libraries. XC32 adds extensions to GCC, such as some builtin functions and probably a lot of other stuff. You'd have to write your own header files, startup code and so on, and I don't even know whether Microchip added instructions to the MIPS instruction set or not. You'd have to look at the XC32 source code extensively to get an idea. The vanilla linker may also not produce proper object code for the PIC32. And then you'd end up with tools you would have a hard time trusting anyway...