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.sherr...@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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
