Re: elftoolchain version of strip unlinks hard-linked files ?

Hi Luigi,

On 24 January 2015 at 03:11, Luigi Rizzo <rizzo_at_iet.unipi.it> wrote:
> I just found that recent versions of 'strip' on head (the change
> occurred between svn 276756 and 277633, not in the code but with
> the change from GNU binutils to the elf toolchain) when operating
> on hard-linked files, creates a new file instead of modifying the
> original:
>
> ...
>
> I believe the elftoolchain is doing it wrong and should be fixed.

I agree that strip ought to leave links intact and will make sure this
gets fixed. Fortunately copy_from_tempfile() already has logic to try
rename() first and fall back to copying otherwise, so it should be
fairly straightforward to add special handling for files with link
count > 1.

If you need a short term workaround you can set
WITHOUT_ELFTOOLCHAIN_TOOLS in src.conf to switch back to the binutils
tools. That said, when installworld strips it does so at install time
and creates links afterwards. Thus this issue won't happen for those
standard targets. Could picobsd make use of that?

> It is also weird that the new strip, despite being statically
> linked, looks up for helper programs somewhere,because if i copy
> it to a different directory it makes the copy but no longer works
> correctly:

No, it doesn't use any helper programs. It's just that strip and
elfcopy are hard-links, and the mode is selected based on argv[0].
This seems reasonable to me, but if there's a need to be able to give
it an arbitrary name I'll undo the link and make it always operate as
strip. Otherwise, I think a reasonable enhancement would be to check
also for *-strip.