On Tue, Nov 22, 2011 at 8:47 AM, Chad Parker <parker.char...@gmail.com> 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á <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
>
>
------------------------------------------------------------------------------
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
