https://sourceware.org/bugzilla/show_bug.cgi?id=31761
--- Comment #8 from Peter Damianov ---
(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
https://sourceware.org/bugzilla/show_bug.cgi?id=31761
--- Comment #5 from Peter Damianov ---
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
https://sourceware.org/bugzilla/show_bug.cgi?id=31761
--- Comment #2 from Peter Damianov ---
I see. Ideally, ld wouldn't be doing that.
One option could be outputting to a temp file, and then renaming it after
linking finishes successfully. I'll try taking a look at what mold does for
this case.
https://sourceware.org/bugzilla/show_bug.cgi?id=31761
Peter Damianov changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: peter0x44 at disroot dot org
Target Milestone: ---
For cases of compiler commands like:
gcc -o file.c -lm
file.c gets deleted, despite that the linking fails (undefined reference to
main)
gcc -fuse-ld=lld
https://sourceware.org/bugzilla/show_bug.cgi?id=31543
Peter0x44 changed:
What|Removed |Added
CC||peter0x44 at disroot dot org
--
You are
