Bug ID: JDK-8268927 Windows: link error: unresolved external symbol "int __cdecl convert_to_unicode(char const *,wchar

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 17	JDK 18
17.0.2Fixed	18 b03Fixed

After the changes in JDK-8238649 some users are experience a build error:

On 17/06/2021 9:47 am, Vitaly Provodin wrote:
> Hi all,
> 
> Building OpenJDK on Windows I am faced with the following error
> 
> ---------------------------8<---------------------------
> os_windows.obj : error LNK2019: unresolved external symbol "int __cdecl convert_to_unicode(char const *,wchar_t * *)" (?convert_to_unicode@@YAHPEBDPEAPEA_W@Z) referenced in function "public: static void __cdecl os::set_native_thread_name(char const *)" (?set_native_thread_name@os@@SAXPEBD@Z)
> c:\buildagent\work\d0555747f6bd5c6\build\windows-x86_64-server-release\support\modules_libs\java.base\server\jvm.dll : fatal error LNK1120: 1 unresolved externals

This is not seen by all users. 

convert_to_unicode is a static function in os_windows.cpp and was used prior to this recent change with set_native_thread_name(). The only difference is that we declared a function prototype for it, as a forward declaration, as it is defined later in the file. It seems the prototype and the definition are subtly different, leading to the linker thinking this is an external reference.

Fix request (17u) Clean backport of the follow-up fix to JDK-8238649.
10-11-2021
Apologies, the fix request was incorrectly added to this issue, it was intended to be added to: JDK-8238649: Call new Win32 API SetThreadDescription in os::set_native_thread_name I've removed the "jdk17u-fix-request" label from this issue and will add it to JDK-8238649.
05-11-2021
[~akasko] Can you please clarify what the follow-up fix is? I think you accidently linked the wrong bug ID above.
05-11-2021
Fix request (17u) Clean backport of a Windows-specific enhancement. Note, there is a follow-up fix: JDK-8268927 to this backport.
03-11-2021
Changeset: e8446107 Author: David Holmes <dholmes@openjdk.org> Date: 2021-06-17 07:02:47 +0000 URL: https://git.openjdk.java.net/jdk/commit/e84461072af9cdb2ee83f5c0747ea5881a0ae805
17-06-2021
g++/gcc confirm this is an error. I have no idea why later VS permits it, when earlier versions did not. I can't find any changelog for VS that relates to this as a known change. Anyway adding the missing static should be fine.
17-06-2021
We don't seem to have a problem using VS 16.9.3 but it does seem that the prototype should have the static storage class modifier to match the definition, otherwise it is assumed to be "extern".
17-06-2021