[RTEMS Project] #2540: RSB has problems building into existing directory

[RTEMS trac]

#2540: RSB has problems building into existing directory
----------------------------+----------------------------
 Reporter:  Simon Williams  |       Owner:  Needs Funding
     Type:  defect          |      Status:  assigned
 Priority:  normal          |   Milestone:  Indefinite
Component:  tool/rsb        |     Version:  5
 Severity:  normal          |  Resolution:
 Keywords:                  |  Blocked By:
 Blocking:                  |
----------------------------+----------------------------

Comment (by Chris Johns):

 Replying to [comment:9 Sebastian Huber]:
 > Replying to [comment:8 Chris Johns]:
 > > Replying to [comment:7 Sebastian Huber]:
 > > > Maybe the RSB should warn that there are already tools installed in
 the prefix and offer an option to remove them.
 > >
 > > A prefix can be a shared resource used by a number of packages so what
 are you asking is removed?
 >
 > What I did is this:
 >
 > find /build/rtems/5/ -name '*or1k*' | xargs rm -r
 >
 > Yes, a bit dangerous. Maybe if a find $prefix -name "*$target*" finds
 something, then we can stop the build. The user has then the choice to
 remove it on its own or use a --force-build-with-existing-tools option.

 It is dangerous. An example of the problems this exposes is the lack of an
 undo, a user attempts a build which fails and the previous working
 installed tools have been removed. I then get requests to not do this.

 > >
 > > I think the real issue is not this but the build. The RSB build of the
 RTEMS tools should be looking to use the binutils just built however for
 some reason gcc must be looking in the `$prefix` before the `$PATH` and
 when the `$prefix` is empty it uses the binutils in the `$PATH`, after all
 this is what happens when there are no tools installed. Does an option
 exist in gcc to control this order?
 >
 > I am not sure if this can be fixed by changes in $PATH. In the GCC build
 tree there is for example an "as" script which is generated:
 >
 > {{{
 > grep -r ORIGINAL_AS_FOR_TARGET
 > gcc/Makefile.in:ORIGINAL_AS_FOR_TARGET = @ORIGINAL_AS_FOR_TARGET@
 > gcc/configure.ac:ORIGINAL_AS_FOR_TARGET=$gcc_cv_as
 > gcc/configure.ac:AC_SUBST(ORIGINAL_AS_FOR_TARGET)
 > gcc/configure.ac:case "$ORIGINAL_AS_FOR_TARGET" in
 > gcc/exec-tool.in:ORIGINAL_AS_FOR_TARGET="@ORIGINAL_AS_FOR_TARGET@"
 > gcc/exec-tool.in:    original=$ORIGINAL_AS_FOR_TARGET
 > gcc/ChangeLog-2005:     * Makefile.in (stamp-as): Use
 $(ORIGINAL_AS_FOR_TARGET)
 > gcc/ChangeLog-2005:     (ORIGINAL_AS_FOR_TARGET, ORIGINAL_LD_FOR_TARGET,
 > gcc/configure:ORIGINAL_AS_FOR_TARGET
 > gcc/configure:ORIGINAL_AS_FOR_TARGET=$gcc_cv_as
 > gcc/configure:case "$ORIGINAL_AS_FOR_TARGET" in
 > }}}
 > It uses absolute paths found during configure time (I guess).

 I think binutils is relocatable so I wonder if the pre-installed tools
 that have been built and waiting for the whole package to finish building
 can be used. Does `--with-as` take a path to an executable?

--
Ticket URL: <http://devel.rtems.org/ticket/2540#comment:10>
RTEMS Project <http://www.rtems.org/>
RTEMS Project