Trying to upgrade the toolchain on an old system (FC8, but heavily
patched.) I have built gcc cross compilers for years now, and am now
hitting a problem I've never seen before.
Built and installed binutils-2.21.1 OK, msp430-as etc are all present in
/usr/local/bin and run.
Building and installation of gcc-4.5.3 succeeds (had some problems with
LD_LIBRARY_PATH, gmp,mpfr,mpc and libelf, but all seem OK now.
Installed msp430mcu-20110612 in /usr/local
Running msp430-gcc fails because it invokes "as" instead of "msp430-as",
for example:
$ msp430-gcc -v -mcpu=430 -mmcu=msp430f149 -c foo.c
Using built-in specs.
Reading specs from
/usr/local/lib/gcc/msp430/4.5.3/../../../../msp430/lib/msp430mcu.spec
COLLECT_GCC=msp430-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/msp430/4.5.3/lto-wrapper
Target: msp430
Configured with: ../configure --target=msp430 --enable-languages=c
--program-prefix=msp430- --with-mpfr-include=/usr/local/include
-with-mpfr-lib=/usr/local/lib --with-gmp-include=/usr/local/include
-with-gmp-lib=/usr/local/lib --with-mpc-include=/usr/local/include
-with-mpc-lib=/usr/local/lib --with-libelf=/usr/local
Thread model: single
gcc version 4.5.3 (GCC)
COLLECT_GCC_OPTIONS='-v' '-mcpu=430' '-mmcu=msp430f149' '-c' '-mcpu=430'
'-mmpy=16' '-mivcnt=16'
/usr/local/libexec/gcc/msp430/4.5.3/cc1 -quiet -v -imultilib mmpy-16
-D__MSP430F149__ foo.c -mcpu=430 -mcpu=430 -mmpy=16 -mivcnt=16 -quiet
-dumpbase foo.c -mcpu=430 -mmcu=msp430f149 -mcpu=430 -mmpy=16 -mivcnt=16
-auxbase foo -version -o /tmp/ccS0mXzJ.s
GNU C (GCC) version 4.5.3 (msp430)
compiled by GNU C version 4.1.2 20070925 (Red Hat 4.1.2-33), GMP
version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/local/lib/gcc/msp430/4.5.3/../../../../msp430/sys-include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/lib/gcc/msp430/4.5.3/include
/usr/local/lib/gcc/msp430/4.5.3/include-fixed
/usr/local/lib/gcc/msp430/4.5.3/../../../../msp430/include
End of search list.
GNU C (GCC) version 4.5.3 (msp430)
compiled by GNU C version 4.1.2 20070925 (Red Hat 4.1.2-33), GMP
version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 78d7aeedccea56aa6fe2a0cb6ad45419
COLLECT_GCC_OPTIONS='-v' '-mcpu=430' '-mmcu=msp430f149' '-c' '-mcpu=430'
'-mmpy=16' '-mivcnt=16'
as -mcpu=430 -mcpu=430 -mmcu=msp430f149 -o foo.o /tmp/ccS0mXzJ.s
as: unrecognized option `-mcpu=430'
$
During the gcc-4.5.3 configure, it seems to find the correct assembler, not
sure why it's not using it:
...
checking for runtest... no
checking for ar... ar
checking for as... as
checking for dlltool... no
checking for ld... ld
checking for lipo... no
checking for nm... nm
checking for ranlib... ranlib
checking for strip... strip
checking for windres... no
checking for windmc... no
checking for objcopy... objcopy
checking for objdump... objdump
checking for msp430-cc... no
checking for msp430-gcc... msp430-gcc
checking for msp430-c++... msp430-c++
checking for msp430-gcc... msp430-gcc
checking for msp430-gcj... no
checking for msp430-gfortran... no
checking for ar... no
checking for msp430-ar... msp430-ar
checking for as... no
checking for msp430-as... msp430-as
checking for dlltool... no
checking for msp430-dlltool... no
checking for ld... no
checking for msp430-ld... msp430-ld
checking for lipo... no
checking for msp430-lipo... no
checking for nm... no
checking for msp430-nm... msp430-nm
checking for objdump... no
checking for msp430-objdump... msp430-objdump
checking for ranlib... no
checking for msp430-ranlib... msp430-ranlib
...
I know the host platform is very old, but I would like to avoid having
msp430-gcc force an upgrade (I won't bore you with the details), and I
upgraded the avr-gcc toolchain to 4.6.2 on this machine without too many
headaches a few days ago, so there's nothing _intrinsic_ that says recent
versions of gcc won't work.
I do not know what extra debug info would be useful to track this down,
I'll happily supply it if asked.
Has anyone else encountered anything similar, or got any suggestions to try
and fix this ?
Regards,
--
Andy
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
