Just follow the guide on the wiki link I posted earlier (which BTW is VERY
hard to find in the wiki if you don't know the address)
It just works, like a Mac
On Tue, Nov 22, 2011 at 1:03 PM, Peter Bigot <[email protected]> wrote:
> On Tue, Nov 22, 2011 at 8:47 AM, Chad Parker <[email protected]>
> wrote:
> > 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.
>
> Why did you do this? They need to be in both places. Normal
> practice, as you describe later, is to install the unqualified names
> in a target-specific subdirectory; these are used internally by the
> toolchain, while the ones with the target prefix are installed in the
> prefix/bin area and are to be invoked by the user.
>
> If you do a clean install and don't remove the copies that the tools
> expect to reference, does it work?
>
> To my knowledge there's nothing in the installation of binutils and
> gcc for msp430 that is different than installing a cross-compiler for
> any other target. I'm confused why people are having problems with
> this.
>
> Peter
>
> > 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á <[email protected]>
> 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á
> >> [email protected]
> >>
> >>
> >>
> >>
> >> On Nov 20, 2011, at 2:32 PM, Peter Bigot wrote:
> >>
> >> > On Sun, Nov 20, 2011 at 11:11 AM, Andy Warner <[email protected]>
> 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
> >> > [email protected]
> >> > 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
> >> [email protected]
> >> 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
> > [email protected]
> > 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
--
--------------------------------------
Sergio Campamá
[email protected]
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
