Fix debug build failure on Windows ARM64+MSVC

[anthony-linaro]

When compiling natively on a Windows ARM64 machine and using MSVC in a "Debug" configuration, there was a linker error, namely LNK1322.

This patch enables the compiler flag to fix those issues for those builds.

Tested with the following commands:

cmake -DCMAKE_BUILD_TYPE:STRING=Debug -DBUILD_SHARED_LIBS:BOOL=OFF -DBUILD_TESTING:BOOL=ON -DHDF5_BUILD_TOOLS:BOOL=ON ..
cmake --build . --config Debug
ctest -C Debug -j4

Testing done on a Thinkpad T14s Gen6 (Snapdragon X Elite), with VS2022.

[byrnHDF]

Wouldn't these changes be needed for all the libraries?

[anthony-linaro]

Not necessarily - the linker error only triggers in certain edge-cases, which the C library happened to hit

Is there a set of commands I can use to test the other libraries, if the lines I gave didn't build them?

[byrnHDF]

Not necessarily - the linker error only triggers in certain edge-cases, which the C library happened to hit

Is there a set of commands I can use to test the other libraries, if the lines I gave didn't build them?

release_docs/INSTALL_CMAKE.txt shows the default options in sectio VI. the default options are at the beginning of that section:

---------------- General Build Options ------------------------------------- BUILD_SHARED_LIBS "Build Shared Libraries" ON BUILD_STATIC_LIBS "Build Static Libraries" ON BUILD_STATIC_EXECS "Build Static Executables" OFF BUILD_TESTING "Build HDF5 Unit Testing" ON if (WINDOWS) HDF5_DISABLE_PDB_FILES "Do not install PDB files" OFF

---------------- HDF5 Build Options ---------------------------------------- HDF5_BUILD_CPP_LIB "Build HDF5 C++ Library" OFF HDF5_BUILD_EXAMPLES "Build HDF5 Library Examples" ON HDF5_BUILD_FORTRAN "Build FORTRAN support" OFF HDF5_BUILD_JAVA "Build JAVA support" OFF HDF5_BUILD_HL_LIB "Build HIGH Level HDF5 Library" ON HDF5_BUILD_TOOLS "Build HDF5 Tools" ON HDF5_BUILD_PARALLEL_TOOLS "Build Parallel HDF5 Tools" OFF HDF5_BUILD_STATIC_TOOLS "Build Static Tools Not Shared Tools" OFF

[anthony-linaro]

@byrnHDF Thanks for that, not sure how I missed it when I was reading the docs! Would the following command line (where I switched a number of options on) suffice for making sure things were compiled? Have I missed anything obvious?

cmake -DCMAKE_BUILD_TYPE:STRING=Debug -DBUILD_STATIC_EXECS=ON -DHDF5_BUILD_CPP_LIB=ON -DHDF5_BUILD_PARALLEL_TOOLS=ON -DHDF5_BUILD_STATIC_TOOLS=ON -DBUILD_TESTING:BOOL=ON -DHDF5_BUILD_TOOLS:BOOL=ON ..

[hyoklee]

@anthony-linaro , thank you for your PR!

I could confirm the LNK1322 problem using cross-compiler. Are you seeing the same 7 errors here?

[anthony-linaro]

@hyoklee - Yes, those are the same errors

I've been looking at enabling wider tooling with the following command line:

cmake -G"Ninja" -DCMAKE_BUILD_TYPE:STRING=Debug -DBUILD_STATIC_EXECS=ON -DHDF5_BUILD_CPP_LIB=ON -DHDF5_BUILD_PARALLEL_TOOLS=ON -DHDF5_BUILD_STATIC_TOOLS=ON -DBUILD_TESTING:BOOL=ON -DHDF5_BUILD_TOOLS:BOOL=ON ..

Sadly, even with /Gy specified, it still seems to be throwing those errors on my machine when building those extra libraries - does your build on cdash build additional things like the CPP lib too?

[jhendersonHDF]

Sadly, even with /Gy specified, it still seems to be throwing those errors on my machine when building those extra libraries - does your build on cdash build additional things like the CPP lib too?

As @byrnHDF mentioned, some of the components of HDF5 may also need a target_link_options made on them if you enable those components. I don't know that we currently have a "full build" test, but it would involve at least HDF5_ALLOW_UNSUPPORTED=ON HDF5_BUILD_CPP_LIB=ON HDF5_BUILD_FORTRAN=ON HDF5_BUILD_JAVA=ON HDF5_ENABLE_PARALLEL=ON.

[anthony-linaro]

This is with /Gy forcibly set for every single file, as a test - sadly it looks like it's not possible to compile anything but the C library (and other associated things like tests in the default build) in Debug mode for these platforms - I have included some relevant extracts:

CMD:

[792/3112] Linking C executable bin\dtypes.exe
FAILED: bin/dtypes.exe
C:\Windows\system32\cmd.exe /C "cd . && "C:\Program Files\CMake\bin\cmake.exe" -E vs_link_exe --intdir=test\CMakeFiles\dtypes.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\arm64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\arm64\mt.exe --manifests  -- C:\PROGRA~1\MICROS~3\2022\COMMUN~1\VC\Tools\MSVC\1442~1.344\bin\HOSTAR~1\arm64\link.exe /nologo test\CMakeFiles\dtypes.dir\dtypes.c.obj  /out:bin\dtypes.exe /implib:bin\dtypes.lib /pdb:bin\dtypes.pdb /version:0.0 /machine:ARM64 -stack:10000000 /debug /INCREMENTAL /subsystem:console  bin\hdf5_test_D.lib  bin\hdf5_D.lib  shlwapi.lib  kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cd ."
LINK Pass 1: command "C:\PROGRA~1\MICROS~3\2022\COMMUN~1\VC\Tools\MSVC\1442~1.344\bin\HOSTAR~1\arm64\link.exe /nologo test\CMakeFiles\dtypes.dir\dtypes.c.obj /out:bin\dtypes.exe /implib:bin\dtypes.lib /pdb:bin\dtypes.pdb /version:0.0 /machine:ARM64 -stack:10000000 /debug /INCREMENTAL /subsystem:console bin\hdf5_test_D.lib bin\hdf5_D.lib shlwapi.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTFILE:test\CMakeFiles\dtypes.dir/intermediate.manifest test\CMakeFiles\dtypes.dir/manifest.res" failed (exit code 1322) with the following output:
dtypes.c.obj : fatal error LNK1322: cannot avoid potential ARM hazard (Cortex-A53 MPCore processor bug #843419) in section 0x34; please consider using compiler option /Gy if it was not used

build.ninja:

#############################################
# Link the executable bin\dtypes.exe

build bin\dtypes.exe: C_EXECUTABLE_LINKER__dtypes_Debug test\CMakeFiles\dtypes.dir\dtypes.c.obj | bin\hdf5_test_D.lib bin\hdf5_D.lib || bin\hdf5_D.dll bin\hdf5_test_D.dll
  FLAGS = -std:c11 /DWIN32 /D_WINDOWS -wd5105 /Gy /Zi /Ob0 /Od /RTC1 -MDd
  LINK_FLAGS = /machine:ARM64 -stack:10000000 /debug /INCREMENTAL /subsystem:console
  LINK_LIBRARIES = bin\hdf5_test_D.lib  bin\hdf5_D.lib  shlwapi.lib  kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib
  OBJECT_DIR = test\CMakeFiles\dtypes.dir
  POST_BUILD = cd .
  PRE_LINK = cd .
  TARGET_COMPILE_PDB = test\CMakeFiles\dtypes.dir\
  TARGET_FILE = bin\dtypes.exe
  TARGET_IMPLIB = bin\dtypes.lib
  TARGET_PDB = bin\dtypes.pdb

Note it was set as a CFLAG here - upon a further amount of googling, it appears to be the "more correct" way of doing it

[hyoklee]

@anthony-linaro , thank you so much for going extra miles in testing!

Interestingly, I don't see any link issue with your PR + enabling wider tooling configuration for cross-compilation:

https://my.cdash.org/viewBuildError.php?buildid=2803684

I'm using the latest 🌶️ Windows 2025 GitHub Action:

https://github.com/hyoklee/actions/actions/runs/13077623330/workflow

I wish I have the same real machine to help you further.

@hyoklee - Yes, those are the same errors

I've been looking at enabling wider tooling with the following command line:

cmake -G"Ninja" -DCMAKE_BUILD_TYPE:STRING=Debug -DBUILD_STATIC_EXECS=ON -DHDF5_BUILD_CPP_LIB=ON -DHDF5_BUILD_PARALLEL_TOOLS=ON -DHDF5_BUILD_STATIC_TOOLS=ON -DBUILD_TESTING:BOOL=ON -DHDF5_BUILD_TOOLS:BOOL=ON ..

Sadly, even with /Gy specified, it still seems to be throwing those errors on my machine when building those extra libraries - does your build on cdash build additional things like the CPP lib too?

[anthony-linaro]

@hyoklee If it works for you when doing cross-compilation, that is fine - is this mergeable as-is, or should I go with the others' reviews, and try and re-organise where I set the /Gy flag?

[hyoklee]

Hi, @anthony-linaro , I'm fine as is as you an see that I've already approved it.

[byrnHDF]

Is this in anyway related to this: https://linaro.atlassian.net/wiki/spaces/WOAR/pages/28684353912/CMake

[byrnHDF]

Also found: https://stackoverflow.com/questions/77448564/cmake-and-arm64ec-with-github-actions

[byrnHDF]

Github will be adding a Windows on arm64 runner sometime soon. I suggest we return to this issue when that runner is available and not make changes until we can properly test.

[anthony-linaro]

Hi @byrnHDF,

Was there supposed to be a link to something in particular on our CMake page? This PR isn't associated with any of our CMake work, I'm actually just going through adjacent projects to the VFX Reference Platform, and HDF5 came up.

That StackOverflow link is to an issue related to ARM64EC - this PR is for plain ARM64 (not EC, which is a seperate thing, and not really necessary here).

If it appears to compile okay with the cross-compilation, then I'm happy to consider this done - if you want to run tests every time too, then I suppose we can wait for the GHA runners to be released.

Thanks

[byrnHDF]

Was there supposed to be a link to something in particular on our CMake page?

Just did a quick search and thought they might be useful info to keep in mind. Anyways, it seems this works for you, but would you make sure the targets are correct. Line 1140 should be ${HDF5_LIBSH_TARGET}

[jhendersonHDF]

Have we confirmed that this actually works as expected? From the previous comments by @anthony-linaro it seems that that's NOT the case. I also think the other point still stands that flags like this should be put higher up than src/CMakeLists.txt.

[anthony-linaro]

@jhendersonHDF It seems to be working fine when built in the CI run above, so I put it down to a local env issue for myself.

I'll move the flag to a different bit (and apply it properly as a CFLAG as intended) - likely HDFMsvcFlags.cmake and HDFMsvcCXXFlags.cmake - which should deal with both requested changes in one go

[anthony-linaro]

I have updated based on review comments - @hyoklee are you able to re-run the cross-compile as you did previously?

[jhendersonHDF]

@jhendersonHDF It seems to be working fine when built in the CI run above, so I put it down to a local env issue for myself.

I'll move the flag to a different bit (and apply it properly as a CFLAG as intended) - likely HDFMsvcFlags.cmake and HDFMsvcCXXFlags.cmake - which should deal with both requested changes in one go

Sure, I'd just like to be certain that this isn't just a result of differences in environment where both environments are perfectly valid. If you ran into this, it's likely that someone else will as well and just because we don't have issues in one (or a few) particular cross-compile build doesn't mean it's not a problem in another. That said, this seemed at first like something that maybe CMake should be handling internally, but I think more research on that may have been needed.

[jhendersonHDF]

I should mention that I'm just bringing this up due to:

This is with /Gy forcibly set for every single file, as a test - sadly it looks like it's not possible to compile anything but the C library (and other associated things like tests in the default build) in Debug mode for these platforms - I have included some relevant extracts:

So, it seems it may work for us*, but I guess the more interesting question is do you still have link problems with your changes?

[anthony-linaro]

You're right, I had a deeper dig into the differences between the build environments - it appears the difference is -DBUILD_SHARED_LIBS:BOOL=OFF being set on the CI - if I set that locally on my machine, the issues go away.

Digging further into the problem would likely be something that would need to be done by MS as a bug report against MSVC - it looks like perhaps their linker isn't managing to work around the CPU errata appropriately. I could only vaguely speculate as to why it's doing it in dtypes.c, perhaps due to the larger size of the class? It could well be that due to the class being relatively large, it can't do the "usual" fix of replacing the ADRP instructions with ADR, or they have a different workaround in place to clang/gcc that doesn't use the "veneer" functions.

Given this only affects debug builds, would an appropriate fix (for now) be to just throw an error (and tell users to use static libs) if building shared libraries on ARM64 in Debug mode when using MSVC? I can report the bug on MS's tracker, but it may be some time before it's fixed.

[jhendersonHDF]

Given this only affects debug builds, would an appropriate fix (for now) be to just throw an error (and tell users to use static libs) if building shared libraries on ARM64 in Debug mode when using MSVC? I can report the bug on MS's tracker, but it may be some time before it's fixed.

That seems reasonable enough to me, though I'd like to hear opinions from others as well. Maybe a warning or some other form of notification instead of just an error, in case it magically works for someone else and/or it's fixed in the near future?

[jhendersonHDF]

Closing this for now until we start testing on ARM64 runners and can investigate more into whether this is something we can fix on our end. See https://github.com/HDFGroup/hdf5/issues/5457.

[byrnHDF]

Added Github workflows on arm64 Windows runners - no issues noted.

[byrnHDF]

Fixed the GH workflows to actually use arm toolset on windows - hit this issue for Debug. Research shows this is a compiler bug and will be fixed soon in MSVC.