JDK-8265831 : 8257831 broke Windows x86 build
- Type: Bug
- Component: hotspot
- Sub-Component: runtime
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- OS: windows
- Submitted: 2021-04-23
- Updated: 2021-04-29
- Resolved: 2021-04-23
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.
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 |
|---|
17 b20Fixed  |
Related Reports
|
Relates :
|
Description
os_windows.obj : error LNK2019: unresolved external symbol "public: void __thiscall Semaphore::wait_with_safepoint_check(class JavaThread *)" (?wait_with_safepoint_check@Semaphore@@QAEXPAVJavaThread@@@Z) referenced in function "int __cdecl check_pending_signals(void)" (?check_pending_signals@@YAHXZ) d:\priv\openjdk\nb\ntintel\jdk-build-fastdebug\support\modules_libs\java.base\server\jvm.dll : fatal error LNK1120: 1 unresolved externals The error is just a missing include. I have no idea why this only breaks x86 though. It has nothing to do with different calling conventions between caller and callee (a typical pain point on x86 windows). Atm I just assume the Windows x64 build pulls semaphore.inline.hpp via some other includes.
Comments
|