#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
