Re: Patch for crosstool.sh in crosstool-0.37

[Daniel Kegel <dank at kegel dot com>]

Leon Woestenberg wrote:
> > If the build failed and I restarted the build then it will fail at 
> > creating links and either I have delete the links or do a complete 
> > rebuild. To avoid that I have applied this patch where I force the links 
> > to be creared, to crosstools.sh and it seems to fix the problem.
> >
> > --- crosstool.sh.orig   2005-07-18 18:17:19.000000000 -0700
> > +++ crosstool.sh        2005-07-18 18:17:45.000000000 -0700
> > @@ -359,7 +359,7 @@
> >     # instead of the location its configure script claims it searches 
> > (gcc_cv_as), grr
> >     mkdir -p $CORE_PREFIX/$TARGET/bin
> >     for tool in ar as ld strip; do
> > -       ln -s $PREFIX/bin/$TARGET-$tool $CORE_PREFIX/$TARGET/bin/$tool
> > +       ln -sf $PREFIX/bin/$TARGET-$tool $CORE_PREFIX/$TARGET/bin/$tool
>
> For maximum safety when relinking, use the -n option as well.
>
> Otherwise you end up with a link *inside* a referenced (earlier linked)
> directory. (Instead of replacing the link-to-directory).
>
> "ln -snf" is always a safe bet when (re)creating a symbolic link.

Except older versions of ln lack the -n option.
How 'bout I just remove the symlink ahead of time, a la:

       # Remove old symlink to avoid clash on rerun
       # ln -snf is safe, but not portable.
       # Can't test for existence of symlinks reliably
       # rm -f returns nonzero status on Solaris if it fails, so || true to keep script from aborting
       rm -f $CORE_PREFIX/$TARGET/bin/$tool || true
       ln -s $PREFIX/bin/$TARGET-$tool $CORE_PREFIX/$TARGET/bin/$tool

- Dan

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com