On Sun, Nov 20, 2011 at 11:32 AM, Peter Bigot <[email protected]> wrote:
> [...]
> 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.
>
The thing is that gcc doesn't seem to even look for as with a prefix any
more, it searches for "as" in directories that contain bits of the prefix.
I don't remember it being this way back in the 3.x days, but I understand
why that might be desirable.
I guess I used that prefix partially out of inertia, and partially because
it appeared to work for this guy:
https://github.com/sergiocampana/Launchpad/blob/master/README.md
> 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.
>
Understood - for some reason these did _not_ get installed on my system,
which was the cause of the problem. However, it seems like gcc's configure
knew this, but still charged on ahead. I still believe the the root cause
was most likely to be binutils not creating/installing in
/usr/local/msp430/bin, but gcc configure did not adjust it's behaviour
accordingly.
Binutils did correctly install the tools in /usr/local/bin with the target
prefix (and these were subsequently found by gcc configure.)
I was 100% consistent in my configure/install arguments throughout the
process. I doubt this will be a common problem, this was an upgrade on a
very old system, and now there's a work-around.
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
