ninja thinks loadable_module targets with no exports are always out of date

[GoogleCodeExporter]

What steps will reproduce the problem?
1. make a loadable_module target that has an entrypoint (i.e., not a 
ResourceOnlyDLL) but that has no exports.
2. generate ninja files for this
3. note that the build line lists a .dll and a .lib file as its outputs.

The problem is that generator/ninja.py wants to override link.exe's default 
name for import libraries and therefore (in WriteLinkForArch) assumes that a 
DLL with an entrypoint also necessarily contains exports. I think it's harmless 
to specify /IMPLIB:foo to link.exe when no implib is generated, but it is 
harmful to have the implib listed as a target's output when none is to be 
generated.

Some options:

1) Ninja generator assumes an implib should be emitted if either a .def file is 
present or if ExportNamedFunctions is specified. This will be wrong for targets 
that only use __declspec(dllexport), so those targets can explicitly specify 
VCLinkerTool's "ImportLibrary" setting. I don't think the ninja generator 
currently supports this setting so support would need to be added.

2) Ninja generator assumes an implib should be emitted for all 
non-ResourceOnlyDLL targets. A new "SuppressImportLibrary" switch can be added 
for targets with an entrypoint but no exports.

Scott: given that you've been hacking on the ninja generator recently, whaddya 
think? Does anything else come to mind? Do you know of anyone else who might 
have the background to weigh in on other options?

For reference, the 'blacklist_test_dll_3' target in 
https://codereview.chromium.org/118343004/ chrome_elf/blacklist.gypi is an 
example of a target impacted by this.

Original issue reported on code.google.com by grt@chromium.org on 19 Dec 2013 at 5:58

[GoogleCodeExporter]

I think I remember having this problem for regular dlls too (the locale 
ones?)... I vaguely recall forcing it always generate an implib somehow? I 
guess that's gone in favour of the ResourceOnlyDLL setting but maybe the old 
version could be excavated from history and repurposed.

Might need to look at comments along the way to decide if/why it was a bad idea 
too. (I have no memory apparently)

Original comment by scottmg@chromium.org on 19 Dec 2013 at 6:52

[GoogleCodeExporter]

So! A mere... 13 months later I ran into the target above in trying to fix 
https://code.google.com/p/chromium/issues/detail?id=451499 (as you have no 
doubt seen).

There doesn't seem to be any flag to pass to link to tell it to suppress 
generating an import lib (which we could have passed redundantly when we know 
one will not be generated, and then had gyp/ninja look for that).

I also tried "/NOENTRY /ENTRY:_DllMainCRTStartup" with the thought that it 
would trigger the "don't expect an import lib path" in ninja, but then 
actually, we'd tell it to use that entry point. Sadly that doesn't work either 
-- it seems that as soon as you have /ENTRY on the command line, the linker 
doesn't include any of the CRT stub code so it can find the default entry point.

Lacking a hacky way (i.e. without changing gyp) I did your 2) above, and added 
a custom flag that just means "don't expect the linker to generate a .lib file" 
https://codereview.chromium.org/890773004/.

So, no hacky way. I guess I'll do 2) above

Original comment by scottmg@chromium.org on 30 Jan 2015 at 7:09

• Changed state: Started

[GoogleCodeExporter]

(ignore that last bit, one paragraph written early and the other later :)

Original comment by scottmg@chromium.org on 30 Jan 2015 at 7:10

[GoogleCodeExporter]

This is workaround-able now.

Original comment by scottmg@chromium.org on 2 Feb 2015 at 6:44

• Changed state: Fixed