Remove use of dumpbin from post-build checks.

[BillyONeal]

We already understand all the information for DLLs from the existing PE/COFF reader, so we don't need to ask dumpbin to tell us again. Advantages:

• Toolsets don't need to tell us where a dumpbin is to run these checks.
• It's faster because we parse the PE headers once instead of once per check.
• It's faster because we aren't launching a subprocess per library per check.
• It is more resilient in the face of localized systems. (In particular, appcontainer check was probably vulnerable to localization)

Drive by fix:

• DLLs' architecture check was not guarded by BuildPolicy::SKIP_ARCHITECTURE_CHECK.
• There weren't tests for the post build checks here.
• MinGW libs no longer choke the checks. [vcpkg] New policy: SKIP_ARCHITECTURE_CHECK. vcpkg#10398
• LLVM LTO libs no longer choke the checks. [vcpkg] Add policy VCPKG_POLICY_SKIP_DUMPBIN_CHECKS vcpkg#9901
• Failing to parse a lib file no longer crashes vcpkg.

Other notes:

• Static libs aren't checked for problems in dynamic triplets, even though dynamic triplets are allowed to produce static libs. For example, a static lib that wants static CRT in a triplet configuring dynamic CRT is not caught, even though we could do so. I did not fix this one in this change because I expect it to fail a lot of things and so want it to be its own smaller targeted change.

[Neumann-A]

Probably needs testing with stuff generated using clang-cl/llvm-link?

[BillyONeal]

Probably needs testing with stuff generated using clang-cl/llvm-link?

Those are not available in our labs.

[Neumann-A]

Those are not available in our labs.

Doesn't VS nowadays bundle LLVM? I mean there is also a complete ClangCL toolchain if installed (replace für with for and you basically have the English translation):

So why isn't it available ?

But my LLVM triplet is probably not affected due to:

## Policy settings
set(VCPKG_POLICY_SKIP_ARCHITECTURE_CHECK enabled)
set(VCPKG_POLICY_SKIP_DUMPBIN_CHECKS enabled)

although I would really like to remove those two lines.

Will the name of set(VCPKG_POLICY_SKIP_DUMPBIN_CHECKS enabled) be changed?

[BillyONeal]

Doesn't VS nowadays bundle LLVM?

They are very particular about what software goes into the lab that has access to code signing, if that makes sense. I could probably jump through some hoops to get that to happen but I don't think it's worth it for just this. I did manually check a few clang-cl examples and it worked fine.

my LLVM triplet is probably not affected due to: [...]

Skipping dumpbin checks makes sense to me but not sure why you need a skip architecture check? That's probably an interesting repro here...

Regardless I think you'll able to remove those lines after this and #814 land.

Will the name of set(VCPKG_POLICY_SKIP_DUMPBIN_CHECKS enabled) be changed?

I think that just becomes meaningless, since the problem that policy exists to work around will no longer exist.

[BillyONeal]

Depends on #814

[Neumann-A]

Skipping dumpbin checks makes sense to me but not sure why you need a skip architecture check? That's probably an interesting repro here...

see microsoft/vcpkg#10398

[Neumann-A]

I think that just becomes meaningless, since the problem that policy exists to work around will no longer exist.

The policy was added in microsoft/vcpkg#9901 due to dumpbin not running on some of the llvm generated files. I never investigated why this error happened but I know that link is also sometimes not able to consume *.obj and *.lib files generated with llvm.

Note: main llvm PR at the time was microsoft/vcpkg#4609. Current LLVM test pr is microsoft/vcpkg#25897 just ignore the merge conflicts (resolve to upstream); I am still waiting for the boost/msbuild fixes to land before i touch that PR again.

[BillyONeal]

Skipping dumpbin checks makes sense to me but not sure why you need a skip architecture check? That's probably an interesting repro here...

see microsoft/vcpkg#10398

I looked at this and indeed only the first linker member is present. I pushed a fix.

[Neumann-A]

Could you also test the implementation with a static library generated using clang-cl with -flto enabled.
I get LNK4048 running dumpbin on those after the symbol listing. I'll attach one of the smaller libs here.
charset.lib.txt

[BillyONeal]

Could you also test the implementation with a static library generated using clang-cl with -flto enabled. I get LNK4048 running dumpbin on those after the symbol listing. I'll attach one of the smaller libs here. charset.lib.txt

Do you have the matching release lib for this? (I'm adding it to an e2e test)

[BillyONeal]

About to push a fix for this warning output. Before:

After:

[BillyONeal]

Do you have the matching release lib for this? (I'm adding it to an e2e test)

Excuse me I mean the debug one. (The wrong warning output made me confused!)

[BillyONeal]

@Neumann-A You got me to break out hex workshop I hope you're happy

[dg0yt]

Should I change to a UCRT mingw toolchain now? Or is there a knob?

-- Performing post-build validation
warning: Detected outdated dynamic CRT in the following files:
    /home/dg0yt/Projekte/vcpkg/vcpkg/packages/zlib_x64-mingw-dynamic/debug/bin/libzlibd1.dll:msvcrt.dll
    /home/dg0yt/Projekte/vcpkg/vcpkg/packages/zlib_x64-mingw-dynamic/bin/libzlib1.dll:msvcrt.dll

[BillyONeal]

Should I change to a UCRT mingw toolchain now? Or is there a knob?

set(ALLOW_OBSOLETE_MSVCRT ON)

[BillyONeal]

Excuse me, I mean:

set(VCPKG_POLICY_ALLOW_OBSOLETE_MSVCRT ON)

[Neumann-A]

You probably mean set(VCPKG_POLICY_ALLOW_OBSOLETE_MSVCRT enabled) ?

[BillyONeal]

:sigh: