Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mozc_tip32.dll build with Bazel is not 32-bit binary #1102

Closed
yukawa opened this issue Oct 29, 2024 · 1 comment · Fixed by #1103 or #1156
Closed

mozc_tip32.dll build with Bazel is not 32-bit binary #1102

yukawa opened this issue Oct 29, 2024 · 1 comment · Fixed by #1103 or #1156

Comments

@yukawa
Copy link
Collaborator

yukawa commented Oct 29, 2024

Description

mozc_tip32.dll build with Bazel is actually 64-bit binary.

This is a regression introduced by de7615f.

The root cause is that --cpu command line option has been ignored since Bazel 7.0.

As we still rely on --cpu command line option here, we cannot remove --noincompatible_enable_cc_toolchain_resolution until we fully migrate to --platforms command line option.

def _win_executable_transition_impl(
settings, # @unused
attr):
features = []
if attr.static_crt:
features = ["static_link_msvcrt"]
return {
"//command_line_option:features": features,
"//command_line_option:cpu": attr.cpu,
}
_win_executable_transition = transition(
implementation = _win_executable_transition_impl,
inputs = [],
outputs = [
"//command_line_option:features",
"//command_line_option:cpu",
],
)

Our GYP build is not affected by this issue.

Steps to reproduce

Steps to reproduce the behavior:

  1. Build Mozc64.msi
  2. dotnet tool run wix msi decompile Mozc64.msi -x dump
  3. dumpbin /headers dump\File\mozc_tip32.dll | findstr machine

Expected behavior

14C machine (x86)

Actual behavior

8664 machine (x64)

Version or commit-id

74384fd

Environment

  • OS: Windows 11 23H2
yukawa added a commit to yukawa/mozc that referenced this issue Oct 30, 2024
This reverts commit de7615f.

It turns out that --cpu command line option will be silently ignored
with Bazel 7.0 and later unless

  --noincompatible_enable_cc_toolchain_resolution

option is specified [1]. Otherwise 'mozc_tip32.dll' will be built as
a 64-bit executable.

This is a temporary workaround until until we fully migrate to

--platforms

command line option [2].

This commit only affects Windows build with Bazel. Other build
configurations such as GYP build on Windows are not affected.

Closes google#1102.

 [1]: bazelbuild/bazel#7260
 [2]: https://bazel.build/concepts/platforms
hiroyuki-komatsu pushed a commit that referenced this issue Oct 30, 2024
This reverts commit de7615f.

It turns out that --cpu command line option will be silently ignored
with Bazel 7.0 and later unless

  --noincompatible_enable_cc_toolchain_resolution

option is specified [1]. Otherwise 'mozc_tip32.dll' will be built as
a 64-bit executable.

This is a temporary workaround until until we fully migrate to

--platforms

command line option [2].

This commit only affects Windows build with Bazel. Other build
configurations such as GYP build on Windows are not affected.

Closes #1102.

 [1]: bazelbuild/bazel#7260
 [2]: https://bazel.build/concepts/platforms

PiperOrigin-RevId: 691409234
@yukawa
Copy link
Collaborator Author

yukawa commented Dec 28, 2024

Unfortunately this is regressed again with 6dadef1, which updated Bazel version from 7.4.1 to 8.0.0.

Looks like Bazel 8.0 removed --noincompatible_enable_cc_toolchain_resolution option, which we have relied on. We definitely need to fully migrate to --incompatible_enable_cc_toolchain_resolution to go forward.

@yukawa yukawa reopened this Dec 28, 2024
yukawa added a commit to yukawa/mozc that referenced this issue Dec 28, 2024
This is a follow up commit to my previous commit [1], which updated the
Bazel version from 7.4.1 to 8.0.0.

It turns out that

  --noincompatible_enable_cc_toolchain_resolution

is now no-op in Bazel 8.0. Thus there remains no way other than fully
migrating to the new CC toolchain resolution as planned in google#1112.
Otherwise 'mozc_tip32.dll' will be built as a 64-bit executable (google#1102).

This commit consists of two parts:

 1. explicitly register CC toolchains in 'windows.bazelrc'.
 2. Switch from '--cpu' commandline option to '--platforms' commandline
    option in '_win_executable_transition'.

With above 'mozc_tip32.dll' will be built as a 32-bit executable again.

Closes google#1102.
Closes google#1112.

 [1]: 6dadef1
yukawa added a commit to yukawa/mozc that referenced this issue Dec 28, 2024
This is a follow up commit to my previous commit [1], which updated the
Bazel version from 7.4.1 to 8.0.0 (google#1118).

It turns out that

  --noincompatible_enable_cc_toolchain_resolution

is now no-op in Bazel 8.0. Thus there remains no way other than fully
migrating to the new CC toolchain resolution as planned in google#1112.
Otherwise 'mozc_tip32.dll' will be built as a 64-bit executable (google#1102).

This commit consists of two parts:

 1. explicitly register CC toolchains in '.bazelrc'.
 2. Switch from '--cpu' commandline option to '--platforms' commandline
    option in '_win_executable_transition'.

With above 'mozc_tip32.dll' will be built as a 32-bit executable again.

Closes google#1102.
Closes google#1112.

 [1]: 6dadef1
yukawa added a commit to yukawa/mozc that referenced this issue Dec 28, 2024
This is a follow up commit to my previous commit [1], which updated the
Bazel version from 7.4.1 to 8.0.0 (google#1118).

It turns out that

  --noincompatible_enable_cc_toolchain_resolution

is now no-op in Bazel 8.0. Thus there remains no way other than fully
migrating to the new CC toolchain resolution as planned in google#1112.
Otherwise 'mozc_tip32.dll' will be built as a 64-bit executable (google#1102).

This commit consists of two parts:

 1. explicitly register CC toolchains in '.bazelrc'.
 2. Switch from '--cpu' commandline option to '--platforms' commandline
    option in '_win_executable_transition'.

With above 'mozc_tip32.dll' will be built as a 32-bit executable again.

Closes google#1102.
Closes google#1112.

 [1]: 6dadef1
yukawa added a commit to yukawa/mozc that referenced this issue Jan 5, 2025
This is a follow up commit to my previous commit [1], which updated the
Bazel version from 7.4.1 to 8.0.0 (google#1118).

It turns out that

  --noincompatible_enable_cc_toolchain_resolution

is now no-op in Bazel 8.0. Thus we have no other choice than fully
migrating to the new CC toolchain resolution as planned in google#1112.
Otherwise 'mozc_tip32.dll' will be built as a 64-bit executable (google#1102).

This commit consists of two parts:

 1. explicitly register CC toolchains in '.bazelrc'.
 2. Switch from '--cpu' commandline option to '--platforms' commandline
    option in '_win_executable_transition'.

With above 'mozc_tip32.dll' will be built as a 32-bit executable again.

Closes google#1102.
Closes google#1112.

 [1]: 6dadef1
yukawa added a commit to yukawa/mozc that referenced this issue Jan 20, 2025
This reworks my previous PR google#1156 [1] to make Windows bazel build
compatible with

  --noincompatible_enable_cc_toolchain_resolution

option, which is now unconditionally enabled (google#1102) (google#1112).

The difference from the previous approach is that this commit uses
CC toolchains defined by 'rules_cc' rather than the ones implicitly
defined by the Bazel itself.

Given that 'rules_cc' becomes the new home of CC-related rules and
configurations, hopefully this change will reduce the likelihood of
future troubles.

There must be no observable behavior change in the final artifacts.

 [1]: 4aad25e
yukawa added a commit to yukawa/mozc that referenced this issue Jan 20, 2025
This reworks my previous PR google#1156 [1] to make Windows bazel build
compatible with

  --noincompatible_enable_cc_toolchain_resolution

option, which is now unconditionally enabled (google#1102) (google#1112).

The difference from the previous approach is that this commit uses
CC toolchains defined by 'rules_cc' rather than the ones implicitly
defined by the Bazel itself.

Given that 'rules_cc' becomes the new home of CC-related rules and
configurations, hopefully this change will reduce the likelihood of
future troubles.

There must be no observable behavior change in the final artifacts.

 [1]: 4aad25e
yukawa added a commit to yukawa/mozc that referenced this issue Jan 21, 2025
This reworks my previous PR google#1156 [1], which was to make Windows bazel
build compatible with

  --noincompatible_enable_cc_toolchain_resolution

option (google#1102) (google#1112).

The difference from the previous approach is that this commit uses
CC toolchains defined by 'rules_cc' rather than the ones implicitly
defined by the Bazel itself.

Given that 'rules_cc' becomes the new home of CC-related rules and
configurations, hopefully this change will reduce the likelihood of
future troubles.

There must be no observable behavior change in the final artifacts.

 [1]: 4aad25e
yukawa added a commit to yukawa/mozc that referenced this issue Jan 21, 2025
This reworks my previous PR google#1156 [1], which was to make Windows bazel
build compatible with

  --noincompatible_enable_cc_toolchain_resolution

option (google#1102) (google#1112).

The difference from the previous approach is that this commit uses
CC toolchains defined by 'rules_cc' rather than the ones implicitly
defined by the Bazel itself.

Given that 'rules_cc' becomes the new home of CC-related rules and
configurations, hopefully this change will reduce the likelihood of
future troubles.

There must be no observable behavior change in the final artifacts.

 [1]: 4aad25e
yukawa added a commit to yukawa/mozc that referenced this issue Jan 21, 2025
This reworks my previous PR google#1156 [1], which was to make Windows bazel
build compatible with

  --noincompatible_enable_cc_toolchain_resolution

option (google#1102) (google#1112).

The difference from the previous approach is that this commit uses
CC toolchains defined by 'rules_cc' rather than the ones implicitly
defined by the Bazel itself.

Given that 'rules_cc' becomes the new home of CC-related rules and
configurations, hopefully this change will reduce the likelihood of
future troubles.

There must be no observable behavior change in the final artifacts.

 [1]: 4aad25e
hiroyuki-komatsu pushed a commit that referenced this issue Jan 21, 2025
This reworks my previous PR #1156 [1], which was to make Windows bazel
build compatible with

  --noincompatible_enable_cc_toolchain_resolution

option (#1102) (#1112).

The difference from the previous approach is that this commit uses
CC toolchains defined by 'rules_cc' rather than the ones implicitly
defined by the Bazel itself.

Given that 'rules_cc' becomes the new home of CC-related rules and
configurations, hopefully this change will reduce the likelihood of
future troubles.

There must be no observable behavior change in the final artifacts.

 [1]: 4aad25e

PiperOrigin-RevId: 717738755
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant