#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: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.

 >
 > The RSB has no concept or knowledge of what the package actually
 installs so how would it be able to remove these specific parts. This is
 what distro packaging systems do.
 >
 > > For example building the latest or1k tool chain failed since I had the
 previous tools installed in $prefix. During GCC build the Binutils of
 $prefix are used and not the ones which are newly built.
 >
 > All I can suggest is you wrap the RSB in the distro system of your
 choice and deploy the tools that way if you want to track specific files
 in packages.
 >
 > 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).

--
Ticket URL: <http://devel.rtems.org/ticket/2540#comment:9>
RTEMS Project <http://www.rtems.org/>
RTEMS Project
_______________________________________________
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs

Reply via email to