Details
-
Enhancement
-
Resolution: Fixed
-
P4
-
None
-
b04
Description
See https://learn.microsoft.com/en-us/cpp/build/reference/zc-inline-remove-unreferenced-comdat?view=msvc-170
key takeaways:
- This optimization simplifies some of the work the linker does in release builds, or when you specify the /OPT:REF linker option. This compiler optimization can significantly reduce .obj file size and improve linker speeds
- If /Zc:inline is specified, the compiler enforces the C++11 requirement that all functions declared inline must have a definition available in the same translation unit if they're used. When the option isn't specified, the Microsoft compiler allows non-conformant code that invokes functions declared inline even if no definition is visible. For more information, see the C++11 standard, in section 3.2 and section 7.1.2.
When the option is specified, the behavior is more conformant to standards, which helps portability (in fact, the problems encountered while building with Zc:inline also happen when building with clang)
- This compiler option was introduced in Visual Studio 2013 Update 2.
We require VS 2019, so the option is guaranteed to be available.
I observed only 4 linker errors when building with Zc:inline:
xPhysicalMemory.obj : error LNK2001: unresolved external symbol "public: __cdecl XListNode<class XMemory>::~XListNode<class XMemory>(void)" (??1?$XListNode@VXMemory@@@@QEAA@XZ)
xVirtualMemory_windows.obj : error LNK2019: unresolved external symbol "public: unsigned __int64 __cdecl XMemory::start(void)const " (?start@XMemory@@QEBA_KXZ) referenced in function "public: static void __cdecl XVirtualMemoryManagerSmallPages::PlaceholderCallbacks::create_callback(class XMemory const *)" (?create_callback@PlaceholderCallbacks@XVirtualMemoryManagerSmallPages@@SAXPEBVXMemory@@@Z)
xVirtualMemory_windows.obj : error LNK2019: unresolved external symbol "public: unsigned __int64 __cdecl XMemory::end(void)const " (?end@XMemory@@QEBA_KXZ) referenced in function "public: static void __cdecl XVirtualMemoryManagerSmallPages::PlaceholderCallbacks::shrink_from_back_callback(class XMemory const *,unsigned __int64)" (?shrink_from_back_callback@PlaceholderCallbacks@XVirtualMemoryManagerSmallPages@@SAXPEBVXMemory@@_K@Z)
xVirtualMemory_windows.obj : error LNK2019: unresolved external symbol "public: unsigned __int64 __cdecl XMemory::size(void)const " (?size@XMemory@@QEBA_KXZ) referenced in function "public: static void __cdecl XVirtualMemoryManagerSmallPages::PlaceholderCallbacks::create_callback(class XMemory const *)" (?create_callback@PlaceholderCallbacks@XVirtualMemoryManagerSmallPages@@SAXPEBVXMemory@@@Z)
They are easily addressed, for example by adding more includes.
key takeaways:
- This optimization simplifies some of the work the linker does in release builds, or when you specify the /OPT:REF linker option. This compiler optimization can significantly reduce .obj file size and improve linker speeds
- If /Zc:inline is specified, the compiler enforces the C++11 requirement that all functions declared inline must have a definition available in the same translation unit if they're used. When the option isn't specified, the Microsoft compiler allows non-conformant code that invokes functions declared inline even if no definition is visible. For more information, see the C++11 standard, in section 3.2 and section 7.1.2.
When the option is specified, the behavior is more conformant to standards, which helps portability (in fact, the problems encountered while building with Zc:inline also happen when building with clang)
- This compiler option was introduced in Visual Studio 2013 Update 2.
We require VS 2019, so the option is guaranteed to be available.
I observed only 4 linker errors when building with Zc:inline:
xPhysicalMemory.obj : error LNK2001: unresolved external symbol "public: __cdecl XListNode<class XMemory>::~XListNode<class XMemory>(void)" (??1?$XListNode@VXMemory@@@@QEAA@XZ)
xVirtualMemory_windows.obj : error LNK2019: unresolved external symbol "public: unsigned __int64 __cdecl XMemory::start(void)const " (?start@XMemory@@QEBA_KXZ) referenced in function "public: static void __cdecl XVirtualMemoryManagerSmallPages::PlaceholderCallbacks::create_callback(class XMemory const *)" (?create_callback@PlaceholderCallbacks@XVirtualMemoryManagerSmallPages@@SAXPEBVXMemory@@@Z)
xVirtualMemory_windows.obj : error LNK2019: unresolved external symbol "public: unsigned __int64 __cdecl XMemory::end(void)const " (?end@XMemory@@QEBA_KXZ) referenced in function "public: static void __cdecl XVirtualMemoryManagerSmallPages::PlaceholderCallbacks::shrink_from_back_callback(class XMemory const *,unsigned __int64)" (?shrink_from_back_callback@PlaceholderCallbacks@XVirtualMemoryManagerSmallPages@@SAXPEBVXMemory@@_K@Z)
xVirtualMemory_windows.obj : error LNK2019: unresolved external symbol "public: unsigned __int64 __cdecl XMemory::size(void)const " (?size@XMemory@@QEBA_KXZ) referenced in function "public: static void __cdecl XVirtualMemoryManagerSmallPages::PlaceholderCallbacks::create_callback(class XMemory const *)" (?create_callback@PlaceholderCallbacks@XVirtualMemoryManagerSmallPages@@SAXPEBVXMemory@@@Z)
They are easily addressed, for example by adding more includes.
Attachments
Issue Links
- relates to
-
JDK-8311064 Windows builds fail without precompiled headers after JDK-8310728
- Resolved
-
JDK-8288293 Windows/gcc Port
- Draft