From command line to visual studio

[Olórin]

I have something working very well in pure command line :

ifort -c -fpp /O3 /fast file1.f90
ifort -c -fpp /O3 /fast file2.f90
ifort  -dll -o my_lib.dll file1.obj file2.obj
xilib /out:./my_lib.lib file1.obj file2.obj

(I don't have any  !DEC$ ATTRIBUTES DLLEXPORT or !DEC$ ATTRIBUTES ALIAS in my fortran code.)

Then I use my_lib.dll to compile with matlab's mex compiler, and use the whole in matlab code. Everything works perfect. Meaning by that : when I compile with mex and link to my_lib.dll, I don't have link errors telling me that functions that I need from the DLL do not exist. And when I used the mew dll produced in matlab, everything works perfectly well as expected.

Now, I would like to stop compiling from command line and use visual studio.

So I created an intel fortran visual studio library project to which I added my two files file1.f90 and file2.f90, and compiled. No lib file was produced: only a DLL was produced. So I added a def file :

; my_lib.def
EXPORTS
   some_function @1

and declare as module file in visual studio and compiled. I had a link error telling me that some_function was an undefined external symbol.

So in the fortran code I added :

subroutine  some_function(Z, X, Y, T)    
!DEC$ ATTRIBUTES DLLEXPORT::some_function
!DEC$ ATTRIBUTES ALIAS:"some_function" :: some_function

and compiled : no more link error.

Yet, when compiling with mex and linking to my_lib.dll, I do have an unresolved external linking error on some_function, which I did not have in the "pure command line case".

(Even if I see some_function if I open my_lib.dll with dependency walker.)

Also, would I leave the DEC ATTRIBUTES and retried the "pure command line case", it wouldn't work anymore : I would have a unresolved external error on some_function. (Hence the same code could not work in the pure command line case and in the visual studio case.)

I would like to understand what is happening, and also why I don't need DEC ATTRIBUTES stuff in the pure command line case when I seem to need it in the visual studio case.  I would like to have the same code in both cases if possible.

[IanH · Accepted solution]

---

@Olórin wrote:

I have something working very well in pure command line

ifort -c -fpp /O3 /fast file1.f90
ifort -c -fpp /O3 /fast file2.f90
ifort  -dll -o my_lib.dll file1.obj file2.obj
xilib /out:./my_lib.lib file1.obj file2.obj

(I don't have any  !DEC$ ATTRIBUTES DLLEXPORT or !DEC$ ATTRIBUTES ALIAS in my fortran code.)

On Windows, without any symbols being exported, the DLL will be "empty". No import library gets created.

The xilib invocation creates a static library that has all the object code from file1.f90 and file2.f90, but it has nothing to do with the [empty] DLL.

If symbols had been exported from the DLL, then an import library named my_lib.lib would have been created.  Things linked against that import library would go looking for executable code in the DLL at runtime.

Then I use my_lib.dll to compile with matlab's mex compiler, and use the whole in matlab code. Everything works perfect. Meaning by that : when I compile with mex and link to my_lib.dll, I don't have link errors telling me that functions that I need from the DLL do not exist. And when I used the mew dll produced in matlab, everything works perfectly well as expected.

On Windows, you do not typically compile-time link with a DLL - you link with the import library for the DLL.

If you linked with the my_lib.lib static library generated by the xilib invocation above, then my_lib.dll is not being referenced in any way.  If you actually linked against the DLL, then you are using exotic tooling.

Now, I would like to stop compiling from command line and use visual studio.

So I created an intel fortran visual studio library project to which I added my two files file1.f90 and file2.f90, and compiled. No lib file was produced: only a DLL was produced.

As for the command line case - nothing exported, no import library created.

So I added a def file

; my_lib.def
EXPORTS
   some_function @1

and declare as module file in visual studio and compiled. I had a link error telling me that some_function was an undefined external symbol.

Linker symbols are case sensitive. By default, Intel Fortran on Windows will create an all upper case linker symbol for a Fortran identifier. The symbol in the def file is lower case, hence the error.

So in the fortran code I added :

subroutine  some_function(Z, X, Y, T)    
!DEC$ ATTRIBUTES DLLEXPORT::some_function
!DEC$ ATTRIBUTES ALIAS:"some_function" :: some_function

and compiled : no more link error.

... because now the case of the compiler's linker symbol and the def file's matches.  You could also, alternatively, have upper cased the name in the def file.

Yet, when compiling with mex and linking to my_lib.dll, I do have an unresolved external linking error on some_function, which I did not have in the "pure command line case".

(Even if I see some_function if I open my_lib.dll with dependency walker.)

I have not used mex for many years, but I guess/speculate that your command line approach was actually linking to the static library, the DLL was never relevant. Follow your command line approach and then delete the DLL after the ifort /dll command - see what happens with subsequent commands.

[Olórin]

In the command line approch I indeed trashed the dll right after the 

ifort -c -fpp /O3 /fast file1.f90
ifort -c -fpp /O3 /fast file2.f90
ifort  -dll -o my_lib.dll file1.obj file2.obj
xilib /out:./my_lib.lib file1.obj file2.obj

bit and went further with my mex code

mex -setup:"C:\Program Files\MATLAB\R2024a\bin\win64\mexopts\intel_fortran_21_vs2022.xml" FORTRAN
mex -largeArrayDims my_file.f my_fileg.F my_lib.lib -L"C:\Program Files\MATLAB\R2024a\bin\win64"

 which work with the .lib file and without the .dll file.

(In fact the ifort commands were bad translation from a linux

gfortran -cpp -g -c file1.f90
gfortran -cpp -g -c file2.f90
gfortran -dynamiclib -o my_lib.so file1.o file2.o

bad translation indeed as I don't see the (analogue of "my") xilib step there. )

As for the visual studio part, your case-sensitive pointer really made my day : the def file was enough to make it work (with the lib file alone) : I can now compile with visual studio and use mex after. Thank you !