Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29004 Discussions

Issue with FileNotFoundError when calling Fortran DLL in Python related to dgesv

411390
Beginner
674 Views

Dear Intel Fortran Community,

I hope this message finds you well. I am currently working with Intel Fortran and Python, and I have encountered an issue that I am hoping you might be able to help me with.

After compiling a Fortran code using the command:

 

ifx /dll /libs:static /Qmkl sample.f90

 

I attempt to call resulting 'sample.dll' via 'ctypes.CDLL' in Python, but I receive the following error:

 

FileNotFoundError : Could not find module '{sample.dll's folder path}' (or one of its dependencies). Try using the full path with constructor syntax.

 

The file path to 'sample.dll' is correct, and it exists on the system. I have verified that there are no errors in the code or the compilation, but the call from Python does not work, and I have been unable to resolve the issue.
 
Here is a snippet of the Fortran code I am working with, which includes a call to the 'dgesv' routine for solving linear systems:

 

module sample
    use ISO_C_binding
    implicit none
    contains
!*****************************************************************************************************************
    subroutine solve_linear_system(imax, jmax, matA, matB, info, matX) bind(C, name = "solve_linear_system")
        !DEC$ ATTRIBUTES DLLEXPORT :: solve_linear_system
        integer(c_int), intent(in) :: imax
        integer(c_int), intent(in) :: jmax
        real(c_double), intent(in) :: matA(imax, imax)
        real(c_double), intent(in) :: matB(imax, jmax)
        integer(c_int), intent(out) :: info
        real(c_double), intent(out) :: matX(imax, jmax)

        integer(c_int) :: ipiv(imax)

        external dgesv
        call dgesv(imax, jmax, matA, imax, ipiv, matB, imax, info)
        matX = matB

    end subroutine solve_linear_system
!*****************************************************************************************************************
end module sample

 

To resolve this issue, I have tried adding environment variables with dependent DLL folders and experimented with different compile options such as /Qmkl-ilp64, but to no avail.

Any insights or suggestions would be greatly appreciated. Thank you very much for your time and assistance.

Best regards,

0 Kudos
6 Replies
Fengrui
Moderator
522 Views

If the path to sample.dll is correct, it might be the dependencies not in the Python environment. Could you please try linking to oneMKL through Single Dynamic Libray?

Fengrui_0-1740502081288.png

 

0 Kudos
411390
Beginner
468 Views

Thank you for your reply.


I tried the following compile command.

 

ifx /dll /libs:static /Qmkl /I"%MKLROOT%\include" sample.f90 /link mkl_rt.lib

 

 The output was as follows:

 

Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2025.0.4 Build 20241205
Copyright (C) 1985-2024 Intel Corporation. All rights reserved.

Microsoft (R) Incremental Linker Version 14.38.33133.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:sample.dll
-dll
-implib:sample.lib
"-libpath:C:\Program Files (x86)\Intel\oneAPI\mkl\latest\lib"
mkl_rt.lib
sample.obj
   ライブラリ sample.lib とオブジェクト sample.exp を作成中

 

 

However, since the error was not resolved, I tried the following:

  1. Rechecking if "call dgesv" was the cause
    I commented out the line "call dgesv" in the sample Fortran code, and the error was resolved.

  2. Checking the dependent DLL files with the "dumpbin /dependents" command.
    The output was as follows:

 

Microsoft (R) COFF/PE Dumper Version 14.38.33133.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file sample.dll

File Type: DLL

  Image has the following dependencies:

    mkl_rt.2.dll
    KERNEL32.dll

  Summary

        3000 .data
        2000 .pdata
       1A000 .rdata
        1000 .reloc
       26000 .text
        1000 .trace
        2000 _RDATA​​

 

      3.Verifying whether the dependent DLL files (mkl_rt.2.dll and KERNEL32.dll) are being loaded correctly with Dependency Walker.

 

Despite these efforts, the issue persists. I would appreciate any insights or suggestions on how to resolve this issue.

0 Kudos
jimdempseyatthecove
Honored Contributor III
148 Views

Your compiler output indicates that it is linking mkil_rt.lib

whereas the dependency indicates that it is looking for mkl_rt.2.dll

 

There may be an issue what the .lib is looking for.

 

Jim Dempsey

0 Kudos
Ruqiu_C_Intel
Moderator
375 Views

Have you tested oneMKL example(for example, C:\Program Files (x86)\Intel\oneAPI\mkl\latest\share\doc\mkl\examples\examples_core_f.zip\f\lapack\source\dgesvx.f) alone to verify your oneAPI environment is fine?



0 Kudos
411390
Beginner
330 Views

Thank you for your reply.

I copied and pasted the file C:\Program Files (x86)\Intel\oneAPI\mkl\latest\share\doc\mkl\examples\examples_core_f.zip\f\lapack\source\dgesvx.f into my working folder, complied it into an exe file, and ran it.

C:%WorkingFolder%>ifx /Qmkl /o dgesvx.exe dgesvx.f
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2025.0.4 Build 20241205
Copyright (C) 1985-2024 Intel Corporation. All rights reserved.

Microsoft (R) Incremental Linker Version 14.38.33133.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:dgesvx.exe
-subsystem:console
"-libpath:C:\Program Files (x86)\Intel\oneAPI\mkl\latest\lib"
dgesvx.obj

C:%WorkingFolder%>dgesvx.exe
 DGESV Example Program Results

 Solution
  -0.80  -0.39   0.96
  -0.70  -0.55   0.22
   0.59   0.84   1.90
   1.32  -0.10   5.36
   0.57   0.11   4.04

 Details of LU factorization
   8.23   1.08   9.04   2.14  -6.87
   0.83  -6.94  -7.92   6.55  -3.99
   0.69  -0.67 -14.18   7.24  -5.19
   0.73   0.75   0.02 -13.82  14.19
  -0.26   0.44  -0.59  -0.34  -3.43

 Pivot indices
      5      5      3      4      5

Can I consider this as a correct verification of my oneAPI environment?

0 Kudos
Ruqiu_C_Intel
Moderator
229 Views

It shows oneMKL is fine for Fortran from the test.

Let's wait Fortran community provides more comments here.


0 Kudos
Reply