I also recently built the tool chain and discovered this also. I was trying
to create packages for the different elements of the tool chain that didn't
create a /usr/msp430 directory. The prefix I'm using is obviously /usr not
/usr/local. I looked into this a bit and I've included here some of my
findings. Ultimately, I did end up installing the tools into an msp430
specific directory, and the build tools that are invoked are not the ones
in /usr/bin with a msp430- prefix, but the ones in /usr/msp430/bin without
a prefix.
I saw that there were the msp430-<tool name> tools installed in /usr/bin
and so I removed the copies that would have been placed in /usr/msp430/bin.
Of course, after doing this, I was unable to build msp430-libc. It looked
as if the wrong version of the assembler was being used, and indeed it was.
I made a pass at adjusting some environment variables to try to direct the
tools to use the correct version, without success. Admittedly, I probably
could have spent more time with this, but it seemed like things were hard
coded somewhere to look for a program called "as".
I tried to track down the source of this. I think I found it in the
Makefile for binutils on lines 95 and 96:
# -------------------------------------------------
# Miscellaneous non-standard autoconf-set variables
# -------------------------------------------------
...
tooldir = ${exec_prefix}/msp430
build_tooldir = ${exec_prefix}/msp430
I'm not all that familiar with autoconf, but I couldn't find a configure
option that would allow me to change these variables. These paths are the
paths where the tools without the msp430- prefix are installed.
The presence of these variables suggests that binutils is incorporating the
paths to the tools into the build process somehow. Since it seems to be
looking for a dedicated directory to contain all of the tools, and
presumably there aren't any other build tools in a directory labeled
msp430, it seems that there was no need to incorporate the msp430- prefix
into the name of the tool it tries to invoke. That is, since only msp430
build tools would be in an msp430 directory, searching for "as" under
/usr/msp430/bin should result in the correct tool being used.
I was unable to find a way of changing this behavior so that it would look
for the msp430- prefixed tools in /usr/bin. Again, granted, I didn't spend
an extensive amount of time searching.
I was reading something somewhere, probably in the GCC mailing list logs,
about someone who was upset about having an architecture specific directory
under /usr. The impression that I got from reading the exchange was that
having such a directory is actually an appropriate and accepted practice.
Indeed, if you look in /usr, at least on my Slackware machines, there is an
architecture specific path containing copies of the build tools
(/usr/x86_64-slackware-linux). I also examined the avr toolchain, and it
seems to do the same thing, again, on my Slackware machines.
I'm not sure how all of this works out with the FHS, and perhaps my
impressions of the discussion were incorrect. Anyway, ultimately I caved in
and installed the msp430 specific tools and libraries into /usr/msp430.
I don't know if any of this information is helpful or useful to anyone, but
at least now it will be documented somewhere!
Cheers,
--Chad
On Sun, Nov 20, 2011 at 14:00, Sergio Campamá <scamp...@ing.puc.cl> wrote:
> But that configuration option is included in the one on the wiki
>
>
> http://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=Install:fromsource
>
> I followed that guide and it works perfectly...
> ---------------------------------------
> Sergio Campamá
> sergiocamp...@gmail.com
>
>
>
>
> On Nov 20, 2011, at 2:32 PM, Peter Bigot wrote:
>
> > On Sun, Nov 20, 2011 at 11:11 AM, Andy Warner <an...@pobox.com> wrote:
> >> The problem was that msp430-gcc doesn't try and run "msp430-as", it
> tries
> >> to find "as", and looks in some specific places. Strace shows that it is
> >> looking in:
> >>
> >> /usr/local/lib/gcc/msp430/4.5.3/../../../../msp430/bin/
> >
> > I noticed your first message suggested you were configuring gcc with:
> >
> > --program-prefix=msp430-
> >
> > which is not one of the recommended flags in the gcc patch for msp430
> > support. I don't know why that would have something to do with it,
> > except that the problem seems to involve the wrong guess for a program
> > prefix.
> >
> > If the process you used to build binutils and gcc isn't consistent
> > with the process described at the top of the toolchain patches
> > (specifically in terms of configuration options and the need to build
> > outside the source tree), something there might be the basis of the
> > problem. With normal configuration, none of the cross-compiler tools
> > should be installed in ${bindir} without a target prefix; they're only
> > installed that way inside
> > ${prefix}/${target}/bin---/usr/local/msp430/bin, in your case---which
> > is not normally in the path.
> >
> > Peter
> >
> >
> ------------------------------------------------------------------------------
> > 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
>
>
>
> ------------------------------------------------------------------------------
> 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
>
------------------------------------------------------------------------------
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
