+Penny who is looking into elf stuff nowadays. 

That GN doesn't exclude user32.dll is bad. chrome_elf must not depend on user32.dll, otherwise it gets loaded too late in the process startup sequence for it to work properly. 

If it does this in Release mode as well, then Chrome's startup sequence won't run as expected. 

FWIW, it looks like this is two bugs:

1) a base/ dependency has snuck into elf via logging (logging::DisplayDebugMessageInDialog). This appears to be wrapped in a #if !defined(NDEBUG) check, so might not affect Release builds. 

2) the GN build doesn't properly exclude user32.dll from chrome_elf's link line. This is weird because the BUILD.gn file does include "/NODEFAULTLIB:user32.lib"

The gn build's chrome_elf.dll.rsp file includes "/DELAYLOAD:user32.dll" - maybe that is overriding /NODEFAULTLIB:user32.lib?

I assume we need to fix this prior to shipping a GN build, yes?

It would be safer to fix it, since the current behavior means we could accidentally ship a dependency on user32.dll.

Just letting folks know that work is underway for this.  It's not a super quick fix to remove the dependencies that snuck in with the change to crashpad in chrome_elf.

I want gyp to die too, so I'm sorry this work is holding up GN.  FYI it's underway though.

Question for anyone: what GN args are we using on the try/official Windows bots?  I'm interested in both the officials builds, and also the testing.

I'm asking because we should have seen a test bot failure when these new dependencies snuck in (with either gyp or gn), and the fact that we didn't means we may be testing with either COMPONENT_BUILD, or only DEBUG.

https://cs.chromium.org/chromium/src/chrome_elf/elf_imports_unittest.cc?q=ELFImportsTest&sq=package:chromium&dr=CSs&l=65

That would not be good for chrome_elf testing.

We are using lots of GN args on the try/official Windows bots. I checked a few of the try bots by looking at the generate_build_files with patch stage:

https://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_ng/builds/264756/steps/generate_build_files%20%28with%20patch%29/logs/stdio

and for the win_chromium_rel_ng builder linked above the settings are:

dcheck_always_on = true
ffmpeg_branding = "Chrome"
goma_dir = "E:\\b\\c\\cipd\\goma"
is_component_build = false
is_debug = false
proprietary_codecs = true
symbol_level = 1
target_cpu = "x86"
use_goma = true

So, non-component, non-debug.

We definitely don't have coverage of all permutations and targets, but non-component, non-debug is covered.

An alternate way of seeing what settings we build with is to look at src\tools\mb\mb_config.pyl, or use MB to recreate the settings from a particular builder:

  python tools\mb\mb.py gen //out/win8_chromium_rel -m tryserver.chromium.win -b win8_chromium_ng

@pennymac - this isn't (really) holding up GN, but presumably we need to fix this before we ship a GN-built binary in M54. Have all of your questions been answered?

For now Dirk, thanks.

I'll focus on getting user32 out of chrome_elf first.  Then I'll try to figure out why the try bots aren't running the tests that would have failed and flagged this bad dependency.

FYI: https://bugs.chromium.org/p/chromium/issues/detail?id=647315

I'm thinking of shutting down this ticket now (shout if you disagree).

1) The linker should fail out on user32 if it is configured in GN. (The new bug above.)
2) Our sanity backup are some automated chrome_elf tests that watch for user32.lib immediately loading.  (Example symptom: https://bugs.chromium.org/p/chromium/issues/detail?id=646414)


When one of the above situations fail, someone has introduced a bad dependency (or there's a toolchain failure), and it needs fixing.

Closing seems reasonable if we have sufficient coverage for this issue now. If there is still an outstanding gn issue then we should fix it.