In previous versions (at least 3.28.3 which I upgraded from to 3.31) of cmake finding the iar linker was done by first extracting the architecture of the found compiler `string(TOLOWER "${CMAKE_${_CMAKE_PROCESSING_LANGUAGE}_COMPILER_ARCHITECTURE_ID}" _CMAKE_IAR_LOWER_ARCHITECTURE_ID)` and then assembling the linker executable name (and searching for that) `__append_IAR_tool(LINKER "ilink${_CMAKE_IAR_LOWER_ARCHITECTURE_ID}")` This way it was possible to have a symlink (or script) in e.g. `${HOME}/bin/ilinkarm` and it could be found and used. This is the way our environment is setup within WSL (and really calling the windows binaries wie some hacks around it to make licensing work). Now with commit 564d527c043 this has changed to extracting the architecture from the path of the compiler: #### Modules/CMakeFindBinUtils.cmake ```cmake 115 get_filename_component(__iar_bin_dir "${CMAKE_${_CMAKE_PROCESSING_LANGUAGE}_COMPILER}" DIRECTORY) 116 get_filename_component(__iar_toolkit_dir "${__iar_bin_dir}" DIRECTORY) 117 get_filename_component(__iar_arch_id "${__iar_toolkit_dir}" NAME) ``` Using the above setup in the home directory, will cause `__iar_arch_id` to contain the username and subsequently resolve the linker name to `ilink${USER}` which in my case only works correctly for the one person with the username arm ;) Given that in my environment CMAKE_CXX_COMPILER_ARCHITECTURE_ID is correctly set to ARM I am wondering why the detection for the linker only was changed to be done this way (iarchive, iasmarm, iccarm are still being found correctly so its unlikely that this generally does not work).