From: Chad P. <par...@gm...> - 2011-11-22 17:29:02
|
> Why did you do this? They need to be in both places. I was simply ignorant of what is apparently standard practice. I essentially discovered exactly what you said, that binutils will invoke the tools in a target-specific subdirectory, while the remaining tools with prefixes are for the user to execute. This is not a problem with the toolchain. I think that the problem is simply that people (myself formerly included) don't realize that it is standard practice to have multiple copies of the tools installed in the system. This is because many people that want to use the toolchain do not actually understand the entire build process well enough. Cheers, --Chad On Tue, Nov 22, 2011 at 11:03, Peter Bigot <bi...@ac...> wrote: > On Tue, Nov 22, 2011 at 8:47 AM, Chad Parker <par...@gm...> > 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á <sca...@in...> > 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á > >> ser...@gm... > >> > >> > >> > >> > >> On Nov 20, 2011, at 2:32 PM, Peter Bigot wrote: > >> > >> > On Sun, Nov 20, 2011 at 11:11 AM, Andy Warner <an...@po...> > 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 > >> > Msp...@li... > >> > 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 > >> Msp...@li... > >> 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 > > Msp...@li... > > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > > > > |