Regarding this issue, we can workaround it to pass the linking process by setting some cmake environment variables as follows.

set CMAKE_SHARED_LINKER_FLAGS=/FORCE:MULTIPLE
set CMAKE_MODULE_LINKER_FLAGS=/FORCE:MULTIPLE
set CMAKE_EXE_LINKER_FLAGS=/FORCE:MULTIPLE

And eventually, we will update the intel GPU bundle to fix it.

Let me do some analysis here.

Firstly, this issue is that, compiler link stage, it found the same math function have two implenmet. Let's focus on ldexp function, and do some debug.

ucrt.lib(api-ms-win-crt-math-l1-1-0.dll) : error LNK2005: ldexp already defined in libm.lib(ldexp_iface_c99.obj)

From the error message, we found:

1. ldexp in api-ms-win-crt-math-l1-1-0.dll.
2. ldexp in libm.lib, and which is assembly from ldexp_iface_c99.obj.

Let's validate 1, we can use dependency walker to check it:

Yes, it is implenment by Microsoft.

Let's validate 2, and here is another question, which libm.lib involved into this issue?
a. sleef library's.
b. Intel compiler(icx)'s
We mentioned that, the second ldexp is assembly from ldexp_iface_c99.obj.
For sleef, we can find that sleef code didn't has a source code named ldexp_iface_c99, repo: https://github.com/shibatch/sleef.
For icx's, we can also validate it.

We can find intel compiler has a libm.lib. Let's use dumpbin tool to decode this library file. We can scaned ldexp_iface_c99.obj from it.

So far, we can make a conclusion, icx's libm have same functions implenmet as MSFT's lib.

Additional analysis for Intel compiler. Acturally, Intel compiler for performance purpose, it would do some magic operation, to replace system's libm to its.

When I enable torch inductor on Windows CPU, I meet this behavior. Below image show the dependency.

We can comfirm additional icx related libs libmmd.dll and svml_dispmd.dll are involeved. To compatible to this behavior, I add some pre_load code:

I have experience to handle Intel compiler's behaior.

In currently PyTorch XPU build case, Intel compiler only work as host compiler and dedicated for SYCL code compiling. The major code is compiled by MSVC.
Some PyTorch code was compiled by MSVC and linked to MSFT implenmented ldexp. SYCL code was compiled by Intel Compiler and linked to Intel implenmented ldexp. So, we linked to mutiple ldexp.
Intel compiler work as host compiler, need to compatible to MSVC. We need some build option to tell intel compiler don't do the magic optimization operations, and use system(MSFT) implenmented libm functions.

Continued update:

1. We find the Intel compiler build option to disable its libm: https://www.intel.com/content/www/us/en/docs/dpcpp-cpp-compiler/developer-guide-reference/2024-2/no-intel-lib-qno-intel-lib.html . But it is doesn't work.
   Because of the torch_cpu.dll is built by MSVC, but not by intel compiler.

2. For the libm bringed in, I did some research.
   a. Some PyTorch third party submodules, such as sleef, xnnpack. Their cmake files may call find_library(m) to search libm. Usually, they can't find the libm on Windows MSVC environment.
   b. When we build XPU version of PyTorch, we need to source Intel compiler environment. And it will bring its libm to build environment. So, step a on XPU build environment would bring in libm into dependency.

Acturally we can't forbid all current/further third party libraries call find_library(m) on Windows.
Setup /FORCE:MULTIPLE should be the only way to solve the issue. I will submit a PR to automatic configure it for PyTorch XPU build.

Original command:

set CMAKE_SHARED_LINKER_FLAGS=/FORCE:MULTIPLE
set CMAKE_MODULE_LINKER_FLAGS=/FORCE:MULTIPLE
set CMAKE_EXE_LINKER_FLAGS=/FORCE:MULTIPLE

Continued update:

1. We find the Intel compiler build option to disable its libm: https://www.intel.com/content/www/us/en/docs/dpcpp-cpp-compiler/developer-guide-reference/2024-2/no-intel-lib-qno-intel-lib.html . But it is doesn't work.
   Because of the torch_cpu.dll is built by MSVC, but not by intel compiler.
2. For the libm bringed in, I did some research.
   a. Some PyTorch third party submodules, such as sleef, xnnpack. Their cmake files may call find_library(m) to search libm. Usually, they can't find the libm on Windows MSVC environment.
   b. When we build XPU version of PyTorch, we need to source Intel compiler environment. And it will bring its libm to build environment. So, step a on XPU build environment would bring in libm into dependency.

Acturally we can't forbid all current/further third party libraries call find_library(m) on Windows. Setup /FORCE:MULTIPLE should be the only way to solve the issue. I will submit a PR to automatic configure it for PyTorch XPU build.

Original command:

set CMAKE_SHARED_LINKER_FLAGS=/FORCE:MULTIPLE
set CMAKE_MODULE_LINKER_FLAGS=/FORCE:MULTIPLE
set CMAKE_EXE_LINKER_FLAGS=/FORCE:MULTIPLE

Discussed with @EikanWang , add these link flag will hide potential same function name with different parameter issue. So will will withdraw this solution.