-
Notifications
You must be signed in to change notification settings - Fork 386
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
Comments
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
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 |
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
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.mozc/src/win32/installer/transition.bzl
Lines 35 to 53 in 74384fd
Our GYP build is not affected by this issue.
Steps to reproduce
Steps to reproduce the behavior:
Mozc64.msi
dotnet tool run wix msi decompile Mozc64.msi -x dump
dumpbin /headers dump\File\mozc_tip32.dll | findstr machine
Expected behavior
Actual behavior
Version or commit-id
74384fd
Environment
The text was updated successfully, but these errors were encountered: