Possible generic RSB issue

[Chris Johns]

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.
>>>> 4.11/rtems-moxie.bset
>>> 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?
> Yes.
>>   That should "just work" I would
>> think.
> 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.

Chris