A chain of messages related to building and packaging is available at: http://www.mail-archive.com/mspgcc-users@lists.sourceforge.net/msg12028.html
At least two of us have successfully built toolchains with those instructions; how to convert them into packaging for a particular distribution isn't something that's likely to come from this list. My recommendation is follow the distribution's standard practices for cross-compilation toolchains and look to existing solutions like AVR and ARM for guidance. TI makes some material available on: http://www.ti.com/tool/msp430-gcc-opensource Personally I would not package a vendor-supplied fork, but that's a policy decision for the distribution. I notice that the most recent TI toolchain 371 (which is an update to version 317 that comes with the CCS 6.0.0-190 release) has been posted there in binary and source form. The old source releases have been removed. I've reminded TI that the GPL licensing may require that they remain available but am leaving any fights in that battle to anybody who cares. The upstream software (gcc, binutils, newlib) is incomplete: you do need the headers and linker files from TI, which are available on TI's page. TI has not provided recommended integration practices for the headers and linker scripts, nor promises related to maintenance/compatibility/etc, so we're on our own. In the days of mspgcc those were carefully separated out as msp430mcu so you could update the available MCUs without updating the toolchain; it would be nice if new packaging solutions followed that practice. Although I've preferred to install those out-of-tree and add compiler flags so the toolchain locates them, I think it's better to follow Eric's recommendations in http://www.mail-archive.com/mspgcc-users%40lists.sourceforge.net/msg12046.html and overlay them into the toolchain installation directory so they're found without special arguments. I noticed that __delay_cycles has been pushed to gcc trunk (though not gcc-4_9-branch) so when I finish some other projects I'll be coming back and checking out the latest versions of everything. newlib-nano does work, though I'm still unhappy with the vendor-specific and undocumented sys interface, and may fork an alternative. C++ is viable but using C++ runtime features is probably not practical due to code size. Once I've switched to using msp430-elf-gcc all pretense that mspgcc is supported will vanish. Unofficially, that's already occurred. Peter On Mon, May 19, 2014 at 3:52 AM, Lev Serebryakov <l...@serebryakov.spb.ru> wrote: > Hello, DJ. > You wrote 19 мая 2014 г., 1:15:28: > > It looks like that this toolchain is not ready for packaging :( > > binutils-2.24 could not build newlib-2.1 (known problem, according to this > list). > > Latest binutils (2.24.51) could not be built by itself, due to errors: > > cc -DHAVE_CONFIG_H -I. > -I/usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/binutils-2.24.51/binutils > -I. > -I/usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/binutils-2.24.51/binutils > -I../bfd > -I/usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/binutils-2.24.51/binutils/../bfd > > -I/usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/binutils-2.24.51/binutils/../include > > -DLOCALEDIR="\"/usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/install/gcc-msp430-embedded-2.24.51.4.9.0.2.1.0/share/locale\"" > -Dbin_dummy_emulation=bin_vanilla_emulation -W -Wall -Wstrict-prototypes > -Wmissing-prototypes -Wshadow -Werror -O2 -pipe -fno-strict-aliasing > -Wno-error -MT bucomm.o -MD -MP -MF .deps/bucomm.Tpo -c -o bucomm.o > /usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/binutils-2.24.51/binutils/bucomm.c > /usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/binutils-2.24.51/binutils/bucomm.c:130:1: > error: variable has incomplete type 'void' > fatal VPARAMS ((const char *format, ...)) > ^ > /usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/binutils-2.24.51/binutils/bucomm.c:130:6: > error: expected ';' after top level declarator > fatal VPARAMS ((const char *format, ...)) > ^ > ; > 2 errors generated. > gmake[6]: *** [bucomm.o] Error 1 > > > And there is not "intermediate" snapshots between them! > > -- > // Black Lion AKA Lev Serebryakov <l...@serebryakov.spb.ru> > > > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. > Get unparalleled scalability from the best Selenium testing platform available > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > _______________________________________________ > Mspgcc-users mailing list > Mspgcc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mspgcc-users ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
