problem building 64.0.3282.0 on Windows 2012 R12

[Demetrios Tsillas]

I am seeing the following error when trying to compile on Windows using VS2017.

My args.gn:

  is_component_build = true

  is_debug = false

  dcheck_always_on = true

  is_official_build = false

  enable_precompiled_headers = false

The error:

/e/jtsillas/Work/workspace3/src ((HEAD detached at 64.0.3282.0)) $ ninja -C out/Release

ninja: Entering directory `out/Release'

[1/1] Regenerating ninja files

[8646/56908] LINK crashpad_util_test_process_info_test_child.exe crashpad_util_test_process_info_test_child.exe.pdb

FAILED: crashpad_util_test_process_info_test_child.exe crashpad_util_test_process_info_test_child.exe.pdb

C:/Python27/python.exe ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64 False link.exe /nologo /OUT:./crashpad_util_test_process_info_test_child.exe /PDB:./crashpad_util_test_process_info_test_child.exe.pdb @./crashpad_util_test_process_info_test_child.exe.rsp

LINK : warning LNK4281: undesirable base address 0x78000000 for x64 image; set base address above 4GB for best ASLR optimization

LINK : error LNK1218: warning treated as error; no output file generated

[8683/56908] CXX obj/third_party/angle/src/vulkan_support/VkLayer_core_validation/core_validation.obj

ninja: build stopped: subcommand failed.

[Demetrios Tsillas]

I added target_cpu = "x86" and it got further but now I see:

/e/jtsillas/Work/workspace3/src ((HEAD detached at 64.0.3282.0)) $ ninja -C out/Release

ninja: Entering directory `out/Release'

[20433/68895] ACTION //remoting/host/win:messages(//build/toolchain/win:win_clang_x86)

FAILED: gen/remoting/host/win/remoting_host_messages.h gen/remoting/host/win/remoting_host_messages.rc

C:/Python27/python.exe ../../build/win/message_compiler.py environment.x86 -h gen/remoting/host/win -r gen/remoting/host/win -u gen/remoting/host/win/remoting_host_messages.mc

mc.exe output different from files in E:\jtsillas\Work\workspace3\src\build\win\..\..\third_party\win_build_output\mc/remoting/host/win, see c:\users\jtsillas\appdata\local\temp\3\tmpdey1yg

[bruce...@chromium.org]

What version of VS are you using? It looks like that x64 warning is new in VS 15.5 and we'll need to land a patch to fix it. Until then you can avoid that warning/error by not trying to build the entire chrome repo - just build the targets that you care about, typically "ninja -C out/Release chrome". However, I can't actually reproduce that warning. Maybe somebody fixed it already?

Do you have the 15063 (Creators Update) SDK installed? Chromium needs to build with that version. That said, I'm not sure why you're getting the mc.exe mismatch because message_compiler.py is only supposed to complain about mismatches if you are using the 15063 version of mc.exe. It may be that you are not using the latest version of the 15063 SDK.

https://cs.chromium.org/chromium/src/build/win/message_compiler.py?q=message_compiler.py&l=69

Also, what commit are you building from? "git log -1 --oneline origin/master"

[Demetrios Tsillas]

Yes I am using VS 15.5. I will see if I can install 15.3 unless a fix is imminent.

I have 15063.675 SDK installed. But I also have 14393.33 - I was using the older SDK to build older versions of chromium (like 62).

I am building from this commit:

commit 057348d452abc0ded12cc2abc1a1c82903ffa2f9

Author: chrome-release-bot <chrome-re...@chromium.org>

Date:   Thu Nov 30 22:53:48 2017 -0800

    Publish DEPS for Chromium 64.0.3282.0

[Bruce Dawson]

Unfortunately Microsoft doesn't make it easy to install old versions of VS 2017, so 15.3 may not be possible.

If you can find where 0x78000000 is set then you can look at trunk to find the change that removed it and apply that fix locally, or else turn off warnings-as-errors for the linker with fatal_linker_warnings=false. Or you could try using lld instead of Microsoft's linker with use_lld=true.

For the message_compiler issue you could modify message_compiler.py to early out instead of checking the results.

These are all workarounds rather than actual solutions, but workarounds are often needed when not building trunk.

On Mon, Jan 8, 2018 at 8:17 AM, Demetrios Tsillas <jtsi...@gmail.com> wrote:

Yes I am using VS 15.5. I will see if I can install 15.3 unless a fix is imminent.

I have 15063.675 SDK installed. But I also have 14393.33 - I was using the older SDK to build older versions of chromium (like 62).

I am building from this commit:

commit 057348d452abc0ded12cc2abc1a1c82903ffa2f9

Author: chrome-release-bot <chrome-release-bot@chromium.org>

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to a topic in the Google Groups "Chromium-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/chromium-dev/hYv_-bGvm2g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chromium-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/16a9327b-1161-446f-83ae-520d421c1266%40chromium.org.

[Demetrios Tsillas]

I uninstalled our SDK (which was version 15063.674 and installed 15063.468. This appeared to fix the mc.exe problem.

Where would I look for a place where the base address in set for the linker?

On Monday, January 8, 2018 at 1:59:00 PM UTC-5, Bruce Dawson wrote:

Unfortunately Microsoft doesn't make it easy to install old versions of VS 2017, so 15.3 may not be possible.

If you can find where 0x78000000 is set then you can look at trunk to find the change that removed it and apply that fix locally, or else turn off warnings-as-errors for the linker with fatal_linker_warnings=false. Or you could try using lld instead of Microsoft's linker with use_lld=true.

For the message_compiler issue you could modify message_compiler.py to early out instead of checking the results.

These are all workarounds rather than actual solutions, but workarounds are often needed when not building trunk.

On Mon, Jan 8, 2018 at 8:17 AM, Demetrios Tsillas <jtsi...@gmail.com> wrote:

Yes I am using VS 15.5. I will see if I can install 15.3 unless a fix is imminent.

I have 15063.675 SDK installed. But I also have 14393.33 - I was using the older SDK to build older versions of chromium (like 62).

I am building from this commit:

commit 057348d452abc0ded12cc2abc1a1c82903ffa2f9

Author: chrome-release-bot <chrome-re...@chromium.org>

To unsubscribe from this group and all its topics, send an email to chromium-dev...@chromium.org.

[Bruce Dawson]

That's good (if frustrating) to know that 15063.674 is the problem. You wanna file a bug? It's too bad that mc.exe changed between those versions but doesn't print distinguishing version numbers (it prints the first three digits of its version, not the distinguishing final digit).

I would guess that the base address is set in one of the build.gn* files but I couldn't find it and I think it was removed from trunk

To unsubscribe from this group and all its topics, send an email to chromium-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/89657f9d-dced-4c2f-a575-5db6d2e68575%40chromium.org.

[Demetrios Tsillas]

Filed bug https://bugs.chromium.org/p/chromium/issues/detail?id=800319

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/89657f9d-dced-4c2f-a575-5db6d2e68575%40chromium.org.