OPTLINK behavior on error is confusing: leaves broken executable behind

[Geod24]

Transferred from: https://issues.dlang.org/show_bug.cgi?id=5215
Original title: Crash with empty program

@bearophile reported (2010-11-13 15:46:08 CET):

This simple wrong D2 program generates expected linker errors and then an unexpected crash on Windows:

void main();

@donc responded (2010-11-13 19:01:25 CET):

What do you mean, 'unexpected'? It complains that there's no main(). Passing an empty file does exactly the same thing.
(The annoying thing is that it makes an exe anyway, even though the exe is corrupt).

@bearophile responded (2010-11-13 19:46:45 CET):

You are right, sorry. The crash is not caused by the compiler/linker, but by the corrupt exe.

@WalterBright responded (2012-01-20 03:12:34 CET):

The linker is supposed to create an exe file, even if there are errors. This is handy for some special purposes.

@braddr responded (2012-01-20 11:19:27 CET):

What circumstances? I don't have a lot of experience with windows, but binutils ld doesn't leave broken turds when linking fails like that. I can see having a linker option to force it to leave the output alone on error, but not having that as the default behavior. Would you treat dmd leaving a .obj file around if there are syntax errors in the .d being built?

@AndrejMitrovic responded (2012-01-20 11:31:54 CET):

Optlink has a /DELEXECUTABLE flag for deleting the exe if there are linker errors, but it doesn't work (I assume because optlink creates warnings instead of errors for OPs code).

Additionally optlink creates executables even if you don't pass anything to it, e.g.:

$ link.exe
creates .exe

The linker gives you warnings and creates a .exe file. Pretty stupid behavior if you ask me. Every modern console app would display a list of arguments you can pass to it, or a sane warning instead of "OPTLINK : Warning 134: No Start Address" when you didn't pass a single file to it.

@WalterBright responded (2012-01-20 13:47:06 CET):

The special purposes are when parts of your program are missing, but you want to link and run the rest of it.

I'm not sure why /delexecutable is not working, though.

[Geod24]

For what it's worth, no linker that I know of leaves broken executable behind. And as @AndrejMitrovic mentioned, many things that are warnings with OPTLINK should probably be errors. Reminds me of how C++ compilers will compile functions without return statement.

[WalterBright]

Optlink has that behavior because it was designed to be a replacement for Microsoft's linker, which had that behavior. Optlink was very successful as its creator scrupulously emulated MS-LINK's behavior.

I did things differently with my C and C++ compiler. Customer would say "ZTC doesn't do X." I say "but X is a clear bug by the Standard." Customer says "but Microsoft does X". I say "but X is a bug". Customer says "but Microsoft does X, and Microsoft is always right."

BTW, it is useful to build an executable one can run even when there are errors like undefined symbols.