Possible generic RSB issue
chrisj at rtems.org
Fri Jan 16 01:58:50 UTC 2015
On 16/01/2015 7:13 am, Joel Sherrill wrote:
> On 1/15/2015 2:05 PM, Gedare Bloom wrote:
>> On Thu, Jan 15, 2015 at 2:49 PM, Joel Sherrill
>> <joel.sherrill at oarcorp.com> wrote:
>>> On 1/15/2015 1:47 PM, Gedare Bloom wrote:
>>>> Did you update the binutils version number in the RSB build set? e.g.
>>> Yes. I switched it to git. But moxie is using 2.24.
>>> I removed the old moxie tools from the install point and it is now using
>>> the right as version. Checked by going into gcc build and doing:
>>> ./gcc/as --version
>>> Still needs a gcc update I think but it is by this issue. :)
With who is the question I am wondering about.
>> OK, so the problem seems to be that RSB did not detect that you needed
>> to build a new binutils? I thought the default RSB behavior will build
>> them new and install them.
> It builds the new one but doesn't install it until after the entire
> build completes.
Correct. If the build fails or you use --no-install nothing is
installed. Having a build partial complete and partially install is not
a good idea. It leaves $PREFIX in an unknown state.
> This leaves old binutils installed.
The RSB knows nothing about the files under the $PREFIX. It only
installs into that path.
>> Did you specify the same prefix for
>> installing as the old install point?
>> That should "just work" I would
> It has in the past but the old binutils was sufficient to build the new
> gcc. :)
> I suspect it has always been using previous binutils to build gcc. Not
> the one which will be installed with it.
Correct. The new binutils is built and is installed internally in the
RSB build tree. This is now a fresh build works when the $PREFIX is
empty or does not exist so the RSB is doing the best it can. For some
reason gcc prefers to use the $PREFIX over the $PATH in this case. I am
not why it does this and I do not know of any configure options that
stop this happening.
More information about the devel