[Bug ld/31761] Linker deletes output file even if linking fails

[peter0x44 at disroot dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31761

--- Comment #8 from Peter Damianov <peter0x44 at disroot dot org> ---
(In reply to Alan Modra from comment #6)
> I agree with Nick's comment.  Consider too that if the link had succeeded,
> your source file would have been overwritten (assuming of course that write
> access was allowed to the file).

I'm aware. But this is less likely to happen, perhaps maybe only when linking
libraries that do expect to provide their own main (like SDL). It would be a
lot harder to make this mistake for that case. If you miss out a source file
your code is usually not going to link anyway. 

(In reply to Nick Clifton from comment #7)
> (In reply to Peter Damianov from comment #5)
> > Just to be completely clear, the command is incorrect, but the way ld reacts
> > to the mistake is the problem. In this case, the "file.c" will be deleted,
> > the user has potentially lost a file, and day ruined. I think refusing to
> > delete output here is the correct and preferable thing to do.
> 
> It may seem callous, but if you are using command line tools to build
> programs then I would argue that a certain level of competence is expected,
> and that loosing a source file to a silly mistake is actually a useful
> lesson.
I would argue there are better ways to teach that lesson.
I think it is important for users to be able to learn how to invoke gcc without
risking demotivating problems like these.
> 
> But maybe a compromise solution can be reached here.  As Alan pointed out,
> setting the output file name to the name of an existing source file is going
> to cause problems regardless of whether the link succeeds or fails.  So
> maybe the correct thing to do is to have the "-o <file>" option fail if the
> output name matches the name of an existing file *and* that name matches a
> pattern of known source files (eg *.[cChosS] *.cpp) ?

I tried to implement this in the gcc driver and had some trouble, but I had to
be more careful then because flags like -E and -S needed to be considered.
I think this might also run the risk of maybe breaking some weird configure
scripts.

Just as a test, I tried:
ls /usr/bin/*.*

To see if there was anything it could affect
The most common case of having a suffix was simply a version number (e.g.
x86_64-pc-linux-gnu-gcc-14.1.1, python3.12)
Next was .sh and .pl
mkfs had some instances, like mkfs.ext4, mkfs.vfat
And last were the linkers, ld.mold, ld.bfd,

There wasn't anything this would break, but of course it's a small subset of
what is out there.

> 
> What do you think ?

I think going all this way is not necessary, and simply leaving the file alone
in the case of the link failing would be enough to cover most cases. And it's
already tested/implemented by other linkers.

But, this suggestion of "filename heuristics" could also work. If you think
it's worth it, go for it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.