Thanks for access to the development machines. I've verified that the mspgcc LTS-20110716 git workspaces comprising the upstream GNU releases with the mspgcc patches applied, when built with the mspgcc recommended configuration flags, successfully produce a toolchain on both gabrielli and smetlana under the sid dchroot. Sources and build logs are available in ~pabigot/msp430 on these machines: logs are the files BUILD/lts.*; the script used for the build is msp430/maint/gcc/scripts/test430.sh. The complete installed toolchain is in ~pabigot/msp430/install/lts.
Following Luca's instructions for apt-get source and dpkg-buildpackage, I was unable to build binutils-msp430 (missing files in /usr/src/binutils), and obtained a different build failure in gcc-msp430 on gabrielli than is shown in the debian build logs. My log for that is in ~pabigot/aptstuff/gcc-msp430/dpo on gabrielli. At this point, since the upstream sources build correctly on the target hosts, I can only conclude that the failure is due to something in the debian build tool environment: perhaps the base releases are not binutils-2.21.1a and gcc-4.5.3 (for gcc, a diff of the unpacked apt sources against my patched upstream sources suggest this is the case), or the patches are incomplete/mis-ordered, or the configuration flags are causing problems, or the environment is causing problems. I am not a debian user and don't understand what magic dpkg-build is doing. All I can provide is the demonstration that the patched LTS-20110716 mspgcc toolchain appears to work on the target platform. It's not an effective use of my time to try to figure out the difference between the verified builds and what dpkg is doing. Sorry. Peter
signature.asc
Description: This is a digitally signed message part
