[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 Sebastian Huber):

 Replying to [comment:10 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?

 I have absolutely no confidence in the GCC build system. I am not sure if
 this will ever work reliably. I would

 1. try to detect that an installation exists in the prefix,
 2. stop building if an installation exists unless a special option is
 given.

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