I got a different error that looked like a CRT mismatch (debug component). Maybe same root cause. (?)

What gn settings were you using?

Possibly off-topic, but IIRC the mini_installer build process has problems if out\Default is a debug build because the build system can't tell it is a debug build and assumes release.

Did this ever work or is this a VS 2015 break?

I just hit these errors when building mini_installer, despite having the output directory named to indicate that it is a debug build - is this what you saw Scott?

C:\src\chromium4\src>ninja -C out\Debug_gn_component
ninja: Entering directory `out\Debug_gn_component'
[42 processes, 10942/11435 @ 10.7/s : 1018.158s ] LINK mini_installer.exe
FAILED: C:/python_27_amd64/files/python.exe gyp-win-tool link-wrapper environment.x64 False link.exe /nologo /OUT:mini_installer.exe /PDB:mini_installer.exe.pdb @mini_installer.exe.rsp
MSVCRTD.lib(_init_.obj) : error LNK2019: unresolved external symbol _CrtDbgReport referenced in function _CRT_RTC_INIT
MSVCRTD.lib(_init_.obj) : error LNK2019: unresolved external symbol _CrtDbgReportW referenced in function _CRT_RTC_INITW
MSVCRTD.lib(_error_.obj) : error LNK2019: unresolved external symbol __stdio_common_vsprintf_s referenced in function _vsprintf_s_l
MSVCRTD.lib(_error_.obj) : error LNK2001: unresolved external symbol __C_specific_handler
MSVCRTD.lib(_pdblkup_.obj) : error LNK2019: unresolved external symbol _wmakepath_s referenced in function "int __cdecl GetPdbDllPathFromFilePath(wchar_t const *,wchar_t *,unsigned __int64)" (?GetPdbDllPathFromFilePath@@YAHPEB_WPEA_W_K@Z)
MSVCRTD.lib(_pdblkup_.obj) : error LNK2019: unresolved external symbol _wsplitpath_s referenced in function "int __cdecl GetPdbDllPathFromFilePath(wchar_t const *,wchar_t *,unsigned __int64)" (?GetPdbDllPathFromFilePath@@YAHPEB_WPEA_W_K@Z)
MSVCRTD.lib(_pdblkup_.obj) : error LNK2019: unresolved external symbol wcscpy_s referenced in function "int __cdecl GetPdbDllPathFromFilePath(wchar_t const *,wchar_t *,unsigned __int64)" (?GetPdbDllPathFromFilePath@@YAHPEB_WPEA_W_K@Z)
MSVCRTD.lib(_pdblkup_.obj) : error LNK2019: unresolved external symbol __vcrt_GetModuleFileNameW referenced in function "struct HINSTANCE__ * __cdecl GetPdbDll(void)" (?GetPdbDll@@YAPEAUHINSTANCE__@@XZ)
MSVCRTD.lib(_pdblkup_.obj) : error LNK2019: unresolved external symbol __vcrt_GetModuleHandleW referenced in function "struct HINSTANCE__ * __cdecl GetPdbDll(void)" (?GetPdbDll@@YAPEAUHINSTANCE__@@XZ)
MSVCRTD.lib(_pdblkup_.obj) : error LNK2019: unresolved external symbol __vcrt_LoadLibraryExW referenced in function "struct HINSTANCE__ * __cdecl GetPdbDll(void)" (?GetPdbDll@@YAPEAUHINSTANCE__@@XZ)
mini_installer.exe : fatal error LNK1120: 10 unresolved externals

Yeah, that's what I see. I'm not sure if it's new for 2015, I've had my GN builds set to 2015 for a while now.

What do you mean by "the build system can't tell [if] it is a debug build"? 

GN certainly knows; are you referring to some build script that might be looking at the directory name?

It's create_installer_archive.py that can't tell. Specifically:

def CopyVisualStudioRuntimeDLLs(target_arch, build_dir):
  is_debug = os.path.basename(build_dir).startswith('Debug')
  if not is_debug and not os.path.basename(build_dir).startswith('Release'):
    print ("Warning: could not determine build configuration from "
           "output directory, assuming Release build.")

This should either be fixed or else the gn recommended directory of 'Default' should be updated. But it sounds like that is a separate issue.

This should be fixed; we need to make arbitrary build directory names work where possible.

I recently updated the webkitpy (blink) scripts to check the args.gn in the build directory if it isn't one of the standard names:

https://code.google.com/p/chromium/codesearch?q=layout_tests%2Fport%2Fbase.py#chromium/src/third_party/WebKit/Tools/Scripts/webkitpy/layout_tests/port/factory.py&l=95

I recommend doing something like that.

The original bug report is from my out_gn/Release though so the generated binary is incorrect even with normal out dir names. This in not VS2015 because the same config gyp build works.

This bug is getting sufficiently annoying that I'm grabbing it. I'm starting with the mini_installer link failures that I mentioned in comment #5. After that I'll work through the other issues, filing other bugs if appropriate.

These are the args.gn settings I'm testing with:

is_component_build = true
is_debug = true
is_win_fastlink = true
enable_nacl = false

gn builds of mini_installer are missing /ignore:4199 which is why there are nine of these warnings in the Debug_gn_component x64 builds:
    LINK : warning LNK4199: /DELAYLOAD:cfgmgr32.dll ignored; no imports found from cfgmgr32.dll
so that's an easy fix.

Part of the reason for the linking difference is that the gn builds compile with /RTC1 which then pulls in MSVCRTD.lib, although I'm not yet sure why that is a fatal problem.

There are numerous other changes but I'm ignoring them for now to focus on the link failures.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bc907653b0b0bd505ee0393925517f11713df643

commit bc907653b0b0bd505ee0393925517f11713df643
Author: brucedawson <brucedawson@chromium.org>
Date: Fri Mar 25 07:09:17 2016

Remove /RTC1 switch to let debug mini_installer build

The /RTC1 switch adds references to _RTC_CheckStackVars and
_RTC_InitBase which causes msvcrtd.lib to be pulled in which causes
gn debug builds of mini_installer to fail. /RTC1 is not used in gyp
builds and therefore it should be removed from gn builds unless we
decide that it offers enough value to justify the effort required to put
it back in.

BUG= 596885 

Review URL: https://codereview.chromium.org/1831213002

Cr-Commit-Position: refs/heads/master@{#383261}

[modify] https://crrev.com/bc907653b0b0bd505ee0393925517f11713df643/build/config/compiler/BUILD.gn

The gn component version of setup.exe references five DLLs that the gyp component version of setup.exe does not:

    ipc.dll
    net.dll
    prefs.dll
    protobuf_lite.dll
    url_lib.dll

These show up because the gn setup.exe.rsp file references 218 .obj files explicitly, whereas the gyp setup.exe.rsp file references 4. metrics_state_manager.obj is an example of an object file that ends up pulling in some unwanted DLLs.

Those files are then brought in by (among other things?) "//chrome/installer/util:with_rc_strings" in the lib/public_deps section of chrome\installer\setup\BUILD.gn.

This presumably then delves down into a source-set and source-sets (list of source files) behave differently from a .lib file that includes the same .obj files. That is the fundamental issue, and I'm not sure what the gn-way of fixing this is.

The gyp build pulls in 78 libs whereas the the gn build pulls in just 47, which is consistent with the source-set explanation.

Unfortunately setup.exe links with .lib files such as prefs.dll.lib and crcrypto.dll.lib in both gyp and gn builds. This means that a reference to symbols in these libraries turns into an unsupported DLL reference instead of a link failure.

A standard way of requesting libs instead of source-sets would fix the bug. Removing the references to the unwanted import libraries would help stop this from coming back.

The GN way is to either split the source_sets up into smaller source_sets as needed, or to convert the source_sets into components, i.e., you don't always have to use source_sets. //base, for example, isn't a source_set in a static build.

You can get that behavior by adding the 'component_never_use_source_set' flag on the given component as needed (see //base for the example and comments about usage).

Whether a given component *should* be a library or a source_set, I'd have to take a look at on a case-by-case basis.

Given that component builds of setup.exe are only used (I believe) for occasional developer testing it may be that the best solution is just to add the five DLLs to the list of DLLs that get unpacked with setup.exe. That already includes the CRT DLLs and base.dll so I see no harm in unpacking a few more.

The alternate fixes would all be either disruptive or fragile or both.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fb41afdaca7c25eeb8e416da3f3b2d5d8f067556

commit fb41afdaca7c25eeb8e416da3f3b2d5d8f067556
Author: brucedawson <brucedawson@chromium.org>
Date: Mon Mar 28 19:42:37 2016

Fix mini_installer in gn component builds

Due to its use of source sets the gn component mini_installer build
of setup.exe creates references to six DLLs that would not be needed if
linking with real .lib files (which avoid pulling in unneeded .obj
files). Fixing this to not pull in those DLLs would require significant
effort and would probably end up being fragile.

Therefore the pragmatic fix is to just extract the six extra DLLs. This
represents 22.4 MB of disk space (87% of that is from net.dll) which is
not enough to matter in the context of mini_installer component builds.

BUG= 596885 

Review URL: https://codereview.chromium.org/1835993002

Cr-Commit-Position: refs/heads/master@{#383542}

[modify] https://crrev.com/fb41afdaca7c25eeb8e416da3f3b2d5d8f067556/chrome/tools/build/win/create_installer_archive.py

As far as I know this is fixed now.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c9d3ca02c5b8e74ba10d351e5db7c01ed5094dfb

commit c9d3ca02c5b8e74ba10d351e5db7c01ed5094dfb
Author: brucedawson <brucedawson@chromium.org>
Date: Tue Mar 29 18:17:34 2016

Make missing or misspelled DLLs a build-time failure

While fixing gn component mini_installer I omitted a comma in a list of
file names. The bogus file name this created was not noticed at build
time. This change requires that every file name or pattern in the list
of globs must expand to at least one DLL, thus making a missing comma
a build-time error.

See this URL for the missing comma that almost got commited:
crrev.com/1835993002/diff2/20001:40001/chrome/tools/build/win/create_installer_archive.py

BUG= 596885 

Review URL: https://codereview.chromium.org/1837943002

Cr-Commit-Position: refs/heads/master@{#383773}

[modify] https://crrev.com/c9d3ca02c5b8e74ba10d351e5db7c01ed5094dfb/chrome/tools/build/win/create_installer_archive.py

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4d38569e5af8de3a252fcba0e465cfa7cbb40e2d

commit 4d38569e5af8de3a252fcba0e465cfa7cbb40e2d
Author: brucedawson <brucedawson@chromium.org>
Date: Wed Apr 06 01:25:39 2016

Detect debug/release of out\Default from args.gn

The mini_installer build process was detecting debug versus release
based purely on the directory name, which fails on many gn setups
because there is no standard naming convention. This updates the
debug versus release detection by looking in args.gn if found.

BUG= 596885 

Review URL: https://codereview.chromium.org/1837233003

Cr-Commit-Position: refs/heads/master@{#385362}

[modify] https://crrev.com/4d38569e5af8de3a252fcba0e465cfa7cbb40e2d/chrome/tools/build/win/create_installer_archive.py