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.

Sign up for GitHub

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

Jump to bottom

The symbol file name embedded in mozc_tip32.dll built with Bazel is mozc_tip.pdb rather than mozc_tip32.dll.pdb #1108

Open
yukawa opened this issue Nov 1, 2024 · 0 comments · May be fixed by #1109
Open

The symbol file name embedded in mozc_tip32.dll built with Bazel is mozc_tip.pdb rather than mozc_tip32.dll.pdb #1108

yukawa opened this issue Nov 1, 2024 · 0 comments · May be fixed by #1109
Assignees
@yukawa

Comments

@yukawa
Copy link
Collaborator

yukawa commented Nov 1, 2024

Description

This follows up to the following task, where we started deploying mozc_tip32.dll.pdb to users' environments.

As noted in the commit 0377ddd, the symbol file name embedded in mozc_tip32.dll built with Bazel is mozc_tip.pdb rather than mozc_tip32.dll.pdb. Let's fix this so that we can fully switch to Bazel build to deprecate GYP build.

Steps to reproduce

  1. bazel --bazelrc=windows.bazelrc build --config oss_windows --config release_build //win32/installer:mozc_tip32
  2. cp bazel-bin\win32\installer\mozc_tip32.dll .
  3. dumpbin /headers mozc_tip32.dll | findstr cv

Expected behavior

You would see mozc_tip32.dll.pdb in the output.

Actual behavior

You see mozc_tip.pdb in the output.

Version or commit-id

ad3bee0

Environment

  • OS: Windows 11 23H2
yukawa added a commit to yukawa/mozc that referenced this issue Nov 1, 2024
@yukawa
Redesign Win32 build transition rules
b8f7d9d 
This reworks my previous commits [1][2][3],  which aimed to make it
configurable on which executable should be built with what build
configurations (e.g. CRT link type, target CPU architecture).

One thing we need to further consider is the debug symbol name embedded
in each artifact executable [4].

To generate debug symbols one can use 'generate_pdb_file' feature. The
issue is that the pdb filename is not configurable in 'rules_cc'. For
instance, if the target name is 'mozc_tip32', then 'rules_cc' assumes
that the output pdb file is always 'mozc_tip32.pdb'. To make it
'mozc_tip32.dll.pdb', the target name must be 'mozc_tip32.dll.dll'.
This is why I had do rework Win32 build transition rules.

Implementation note:
 * The reason why 'mozc_win32_cc_prod_binary' needs to be introduced is
   because the final executable name needs to be available as an input
   of 'mozc_cc_binary'.
 * 'mozc_cc_win32_library' also needs to be reworked so that
   'generate_pdb_file' feature will not be applied to it.

There must be no observable change in GYP build and non-Windows bazel
builds.

Closes google#1108.

 [1]: 5efa371
 [2]: ff64988
 [3]: ea55af0
 [4]: 0377ddd
yukawa added a commit to yukawa/mozc that referenced this issue Nov 1, 2024
@yukawa
Redesign Win32 build transition rules
239e513 
This reworks my previous commits [1][2][3], which aimed to make it
configurable on which executable should be built with what build
configurations (e.g. CRT link type, target CPU architecture).

One thing we need to further consider is the debug symbol name embedded
in each artifact executable [4].

To generate debug symbols one can use 'generate_pdb_file' feature. The
issue is that the pdb filename is not configurable in 'rules_cc'. For
instance, if the target name is 'mozc_tip32', then 'rules_cc' assumes
that the output pdb file is always 'mozc_tip32.pdb'. To make it
'mozc_tip32.dll.pdb', the target name must be 'mozc_tip32.dll.dll'.
This is why I had do rework Win32 build transition rules.

Implementation note:
 * The reason why 'mozc_win32_cc_prod_binary' needs to be introduced is
   because the final executable name needs to be available as an input
   of 'mozc_cc_binary'.
 * 'mozc_cc_win32_library' also needs to be reworked so that
   'generate_pdb_file' feature will not be applied to it.

There must be no observable change in GYP build and non-Windows bazel
builds.

Closes google#1108.

 [1]: 5efa371
 [2]: ff64988
 [3]: ea55af0
 [4]: 0377ddd
@yukawa yukawa linked a pull request Nov 1, 2024 that will close this issue
Open
@yukawa yukawa self-assigned this Nov 2, 2024
yukawa added a commit to yukawa/mozc that referenced this issue Nov 19, 2024
@yukawa
Redesign Win32 build transition rules
99f8fe1 
This reworks my previous commits [1][2][3], which aimed to make it
configurable on which executable should be built with what build
configurations (e.g. CRT link type, target CPU architecture).

One thing we need to further consider is the debug symbol name embedded
in each artifact executable [4].

To generate debug symbols one can use 'generate_pdb_file' feature. The
issue is that the pdb filename is not configurable in 'rules_cc'. For
instance, if the target name is 'mozc_tip32', then 'rules_cc' assumes
that the output pdb file is always 'mozc_tip32.pdb'. To make it
'mozc_tip32.dll.pdb', the target name must be 'mozc_tip32.dll.dll'.
This is why I had do rework Win32 build transition rules.

Implementation note:
 * The reason why 'mozc_win32_cc_prod_binary' needs to be introduced is
   because the final executable name needs to be available as an input
   of 'mozc_cc_binary'.
 * 'mozc_cc_win32_library' also needs to be reworked so that
   'generate_pdb_file' feature will not be applied to it.

There must be no observable change in GYP build and non-Windows bazel
builds.

Closes google#1108.

 [1]: 5efa371
 [2]: ff64988
 [3]: ea55af0
 [4]: 0377ddd
yukawa added a commit to yukawa/mozc that referenced this issue Nov 23, 2024
@yukawa
Redesign Win32 build transition rules
fa7c43b 
This reworks my previous commits [1][2][3], which aimed to make it
configurable on which executable should be built with what build
configurations (e.g. CRT link type, target CPU architecture).

One thing we need to further consider is the debug symbol name embedded
in each artifact executable [4].

To generate debug symbols one can use 'generate_pdb_file' feature. The
issue is that the pdb filename is not configurable in 'rules_cc'. For
instance, if the target name is 'mozc_tip32', then 'rules_cc' assumes
that the output pdb file is always 'mozc_tip32.pdb'. To make it
'mozc_tip32.dll.pdb', the target name must be 'mozc_tip32.dll.dll'.
This is why I had do rework Win32 build transition rules.

Implementation note:
 * The reason why 'mozc_win32_cc_prod_binary' needs to be introduced is
   because the final executable name needs to be available as an input
   of 'mozc_cc_binary'.
 * 'mozc_cc_win32_library' also needs to be reworked so that
   'generate_pdb_file' feature will not be applied to it.

There must be no observable change in GYP build and non-Windows bazel
builds.

Closes google#1108.

 [1]: 5efa371
 [2]: ff64988
 [3]: ea55af0
 [4]: 0377ddd
yukawa added a commit to yukawa/mozc that referenced this issue Dec 5, 2024
@yukawa
Redesign Win32 build transition rules
539dfc0 
This reworks my previous commits [1][2][3], which aimed to make it
configurable on which executable should be built with what build
configurations (e.g. CRT link type, target CPU architecture).

One thing we need to further consider is the debug symbol name embedded
in each artifact executable [4].

To generate debug symbols one can use 'generate_pdb_file' feature. The
issue is that the pdb filename is not configurable in 'rules_cc'. For
instance, if the target name is 'mozc_tip32', then 'rules_cc' assumes
that the output pdb file is always 'mozc_tip32.pdb'. To make it
'mozc_tip32.dll.pdb', the target name must be 'mozc_tip32.dll.dll'.
This is why I had do rework Win32 build transition rules.

Implementation note:
 * The reason why 'mozc_win32_cc_prod_binary' needs to be introduced is
   because the final executable name needs to be available as an input
   of 'mozc_cc_binary'.
 * 'mozc_cc_win32_library' also needs to be reworked so that
   'generate_pdb_file' feature will not be applied to it.

There must be no observable change in GYP build and non-Windows bazel
builds.

Closes google#1108.

 [1]: 5efa371
 [2]: ff64988
 [3]: ea55af0
 [4]: 0377ddd
yukawa added a commit to yukawa/mozc that referenced this issue Dec 23, 2024
@yukawa
Propagate linkshared as appropriate
9e52c8c 
This follows up to our previous commit [1], which was a preparation to
address the following isssue but accidentally removed 'linkshared' from
Mozc's TIP DLL targets.

 * google#1108

While a subsequent commit [2] addressed the immediate issue by passing
'static_crt' to 'linkshared', strictly speaking they are two orthogonal
concepts. Let's decouple them to avoid future confusions.

There must be no immediate change in the final artifacts with this
commit right now.

 [1]: bc546b2
 [2]: 8d20ea6
@yukawa yukawa mentioned this issue Dec 23, 2024
Merged
yukawa added a commit to yukawa/mozc that referenced this issue Dec 23, 2024
@yukawa
Propagate linkshared as appropriate
eaffb5e 
This follows up to our previous commit [1], which was a preparation to
address the symbol name mismatch in Mozc's TIP DLLs (google#1108) but
accidentally removed 'linkshared' from them.

While a subsequent commit [2] addressed the immediate issue by passing
'static_crt' to 'linkshared', strictly speaking they are two orthogonal
concepts. Let's decouple them to avoid future confusions.

There must be no immediate change in the final artifacts with this
commit right now.

 [1]: bc546b2
 [2]: 8d20ea6
hiroyuki-komatsu pushed a commit that referenced this issue Dec 26, 2024
@yukawa
Propagate linkshared as appropriate (#1153)
29c3581 
This follows up to our previous commit [1], which was a preparation to
address the symbol name mismatch in Mozc's TIP DLLs (#1108) but
accidentally removed 'linkshared' from them.

While a subsequent commit [2] addressed the immediate issue by passing
'static_crt' to 'linkshared', strictly speaking they are two orthogonal
concepts. Let's decouple them to avoid future confusions.

There must be no immediate change in the final artifacts with this
commit right now.

 [1]: bc546b2
 [2]: 8d20ea6

PiperOrigin-RevId: 709332940
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@yukawa yukawa

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Redesign Win32 build transition rules yukawa/mozc
1 participant
@yukawa