Loosing my mind over an existing dll but a missing library (.lib) (ifort)

[MorsePotential]

Hi fellow members of the community,

I usually manage to sort all my problems through scouring these forums but at this point I am ultimately at my witts end.

TLDR of a problem: LINK : fatal error LNK1104: cannot open file 'libiomp5md.lib'

Now for some details:

I am using a nmake /f makefile to build a program using the ifort compiler.

I launch the nmake from the intel oneapi cmd intel64 env for Visual studio 2023 ( i previously used 2019 and it worked just dandy)

The flags that I use for my .o (object files) are as follows:

/O3 /Qip /Qmkl:parallel /Qopenmp /static

Yes, I have HPC installed.

I have the PATH variable set up in such a way that both .dll and .lib locations are present.
By that I mean \Intel\oneAPI\compiler\latest\windows\redist\intel64_win\compiler,  ONEAPI_ROOT etc.

I really am not sure what I am missing. The only thing that comes to mind is that the "libiomp5md.dll" exists in the \Intel\oneAPI\compiler\2023.1.0\windows\redist\intel64_win\compiler
but the "libiomp5md.lib" does not in the Intel\oneAPI\mkl\latest\lib\intel64 ( but then it probably shouldn't be there?).

The reason I mention the latter is because ifort (post variable setting and all) tells me:
"-libpath:C:\Program Files (x86)\Intel\oneAPI\mkl\latest\lib\intel64"


I tried running without /static, but I need the /Qopenmp for my calculations.

Please help as at this point I am slowly loosing my mind.

[IanH · Accepted solution]

PATH isn't relevant for static/import library (.lib) searches - the linker searches paths in the LIB environment variable (plus whatever it is told on the command line).  Check your makefile isn't munging LIB.

>where "$lib:libiomp5md.lib"
C:\Program Files (x86)\Intel\oneAPI\compiler\latest\windows\compiler\lib\intel64_win\libiomp5md.lib

[MorsePotential]

I think you are right, had a useless LIB declaration, so removed that for the time being.

However now I am getting a new error:

C:\Program
Files
(x86)\Intel\oneAPI\vpl\latest\lib;C:\Program
(x86)\Intel\oneAPI\tbb\latest\env\..\lib\intel64\vc_mt;C:\Program
(x86)\Intel\oneAPI\mpi\latest\env\..\lib\release;C:\Program
(x86)\Intel\oneAPI\mpi\latest\env\..\lib;C:\Program
(x86)\Intel\oneAPI\mkl\latest\lib\intel64;C:\Program
(x86)\Intel\oneAPI\ippcp\latest\lib\intel64;C:\Program
(x86)\Intel\oneAPI\ipp\latest\lib\intel64;C:\Program
(x86)\Intel\oneAPI\dnnl\latest\env\..\cpu_dpcpp_gpu_dpcpp\lib;C:\Program
(x86)\Intel\oneAPI\dal\latest\lib\intel64;C:\Program
(x86)\Intel\oneAPI\compiler\latest\windows\compiler\lib;C:\Program
(x86)\Intel\oneAPI\compiler\latest\windows\compiler\lib\intel64_win;C:\Program
(x86)\Intel\oneAPI\compiler\latest\windows\lib;C:\Program
(x86)\Intel\oneAPI\compiler\latest\windows\lib\x64;C:\Program
Files\Microsoft
Visual
Studio\2022\Enterprise\VC\Tools\MSVC\14.35.32215\ATLMFC\lib\x64;C:\Program
Studio\2022\Enterprise\VC\Tools\MSVC\14.35.32215\lib\x64;C:\Program
(x86)\Windows
Kits\NETFXSDK\4.8\lib\um\x64;C:\Program
Kits\10\lib\10.0.22000.0\ucrt\x64;C:\Program
Kits\10\\lib\10.0.22000.0\\um\x64
LINK : fatal error LNK1181: cannot open input file 'C:\Program.obj'

[jimdempseyatthecove]

Generally speaking, you do not build in the root folder (C:\)

IOW the output file of the compiler would not be to C:\ therefore the input file (Program.obj) would not be located in the root directory.

If C:\Program is the folder for your test program, then it is likely that your linker option to specify the input file name has been placed on the linker option to specify the library search path. .OR. you placed the folder name in the option for the input file name. Check those options.

Jim Dempsey

[MorsePotential]

Hi Ian,

You appear to be right there was a useless LIB argument in the makefile that probably overwritten the default location of where to look.

I ran your command and get the exact same output.

Having removed that LIB argument, I now face a very weird different error. Have you seen something like that?

C:\Program
Files
(x86)\Intel\oneAPI\vpl\latest\lib;C:\Program
(x86)\Intel\oneAPI\tbb\latest\env\..\lib\intel64\vc_mt;C:\Program
(x86)\Intel\oneAPI\mpi\latest\env\..\lib\release;C:\Program
(x86)\Intel\oneAPI\mpi\latest\env\..\lib;C:\Program
(x86)\Intel\oneAPI\mkl\latest\lib\intel64;C:\Program
(x86)\Intel\oneAPI\ippcp\latest\lib\intel64;C:\Program
(x86)\Intel\oneAPI\ipp\latest\lib\intel64;C:\Program
(x86)\Intel\oneAPI\dnnl\latest\env\..\cpu_dpcpp_gpu_dpcpp\lib;C:\Program
(x86)\Intel\oneAPI\dal\latest\lib\intel64;C:\Program
(x86)\Intel\oneAPI\compiler\latest\windows\compiler\lib;C:\Program
(x86)\Intel\oneAPI\compiler\latest\windows\compiler\lib\intel64_win;C:\Program
(x86)\Intel\oneAPI\compiler\latest\windows\lib;C:\Program
(x86)\Intel\oneAPI\compiler\latest\windows\lib\x64;C:\Program
Files\Microsoft
Visual
Studio\2022\Enterprise\VC\Tools\MSVC\14.35.32215\ATLMFC\lib\x64;C:\Program
Studio\2022\Enterprise\VC\Tools\MSVC\14.35.32215\lib\x64;C:\Program
(x86)\Windows
Kits\NETFXSDK\4.8\lib\um\x64;C:\Program
Kits\10\lib\10.0.22000.0\ucrt\x64;C:\Program
Kits\10\\lib\10.0.22000.0\\um\x64
LINK : fatal error LNK1181: cannot open input file 'C:\Program.obj'

[jimdempseyatthecove]

 LINK : fatal error LNK1104: cannot open file 'libiomp5md.lib'

Have you added  \Intel\oneAPI\compiler\2023.1.0\windows\redist\intel64_win\compiler (location of libiomp5md.lib) to the libpath?

Also, to run the program, libiomp5md.dll must be in PATH (or accessible in search path when application is run).

The Intel OpenMP (Windows) library is only supported as a .dll (but you link the .lib to get the entry points).

Jim Dempsey

[MorsePotential]

Hi Jim,

The " \Intel\oneAPI\compiler\2023.1.0\windows\redist\intel64_win\compiler" is definitely specified as part of the libpath

[IanH]

The "..\redist\.." folders do not contain static/import libraries.

The problem in the original post is happening at the link stage.  The location of the DLL is not relevant - that is (very typically) only needed at runtime.

When your makefile tries to run the link (how are you invoking the linker??  Are you calling link.exe, or are you calling through the ifort compiler driver?  Perhaps show your makefile...) what are the contents of the LIB environment variable?  What specifically is the command line that ultimately invokes the linker?

[MorsePotential]

Hi @IanH ,

For some reason, my reply to your previous post never got posted several times in a row

So I am going to try an answer here. You're right it seems that the LIB variable (not used for much) was munging the libraries.

However, once I removed it I got another weird error:

LINK : fatal error LNK1181: cannot open input file 'C:\Program.obj'

It seems like the code breaks at the space in the program files

[MorsePotential]

Full error code:
"C:\Program
Files
(x86)\Intel\oneAPI\vpl\latest\lib;C:\Program
(x86)\Intel\oneAPI\tbb\latest\env\..\lib\intel64\vc_mt;C:\Program
(x86)\Intel\oneAPI\mpi\latest\env\..\lib\release;C:\Program
(x86)\Intel\oneAPI\mpi\latest\env\..\lib;C:\Program
(x86)\Intel\oneAPI\mkl\latest\lib\intel64;C:\Program
(x86)\Intel\oneAPI\ippcp\latest\lib\intel64;C:\Program
(x86)\Intel\oneAPI\ipp\latest\lib\intel64;C:\Program
(x86)\Intel\oneAPI\dnnl\latest\env\..\cpu_dpcpp_gpu_dpcpp\lib;C:\Program
(x86)\Intel\oneAPI\dal\latest\lib\intel64;C:\Program
(x86)\Intel\oneAPI\compiler\latest\windows\compiler\lib;C:\Program
(x86)\Intel\oneAPI\compiler\latest\windows\compiler\lib\intel64_win;C:\Program
(x86)\Intel\oneAPI\compiler\latest\windows\lib;C:\Program
(x86)\Intel\oneAPI\compiler\latest\windows\lib\x64;C:\Program
Files\Microsoft
Visual
Studio\2022\Enterprise\VC\Tools\MSVC\14.35.32215\ATLMFC\lib\x64;C:\Program
Studio\2022\Enterprise\VC\Tools\MSVC\14.35.32215\lib\x64;C:\Program
(x86)\Windows
Kits\NETFXSDK\4.8\lib\um\x64;C:\Program
Kits\10\lib\10.0.22000.0\ucrt\x64;C:\Program
Kits\10\\lib\10.0.22000.0\\um\x64
LINK : fatal error LNK1181: cannot open input file 'C:\Program.obj'"

[IanH]

You need to "debug" your makefile.  Without us being able to see it and/or the command lines that it is trying to execute, it is hard to comment further.

(The LIB variable probably appeared in the makefile for a reason - it perhaps isn't surprising that things break in other ways once you removed it.)

[MorsePotential]

@IanH you seem to be right as again. By commenting it out I forgot to remove it from the For loop, so hence it was adding LIB on the end of object generation. I have removed it now and it from there now and it seems to me everything compiles again.

However, I am not sure why that LIB ever needed to exist. I am putting this makefile here. Perhaps you can help me understand.

goal:   duo

tarball:
    tar cfz duo$(PLAT).tar.gz makefile *.f90
       
checkin:
    ci -l Makefile *.f90


EXE = duo.x

FOR  = ifort

FFLAGS = /O3 /Qip /Qmkl:parallel /Qopenmp

LAPACK = /Qopenmp /Qmkl:parallel

LIB     =   $(LAPACK)
 
OBJ = F1_hyperfine.o F1_intensity.o grids.o accuracy.o lapack.o timer.o input.o diatom.o refinement.o functions.o  symmetry.o dipole.o quadrupole.o magnetic_dipole.o header_info.o atomic_and_nuclear_data.o  Lobatto.o me_numer.o RWF.o

diatom.o: symmetry.o functions.o input.o lapack.o Lobatto.o timer.o atomic_and_nuclear_data.o accuracy.o me_numer.o
dipole.o: timer.o accuracy.o diatom.o symmetry.o
quadrupole.o: timer.o accuracy.o diatom.o symmetry.o
magnetic_dipole.o: timer.o accuracy.o diatom.o symmetry.o
duo.o: header_info.o diatom.o accuracy.o refinement.o timer.o dipole.o F1_hyperfine.o F1_intensity.o
functions.o: accuracy.o timer.o
grids.o: accuracy.o Lobatto.o
header_info.o: accuracy.o
F1_hyperfine.o: accuracy.o diatom.o lapack.o symmetry.o
F1_intensity.o: F1_hyperfine.o accuracy.o diatom.o
me_numer.o : accuracy.o lapack.o timer.o
lapack.o: accuracy.o timer.o
Lobatto.o: accuracy.o timer.o
refinement.o: timer.o accuracy.o diatom.o
symmetry.o: accuracy.o
timer.o: accuracy.o
RWF.o: accuracy.o diatom.o timer.o symmetry.o lapack.o

# clear internal suffix rules
.SUFFIXES:
# specify our own suffix rules
.SUFFIXES: .f90 .o
.f90.o:
    $(FOR) -c -o $@ $< $(FFLAGS)

duo:    $(OBJ) duo.o
    $(FOR) -o $(EXE) $(OBJ) $(FFLAGS) duo.o $(LIB)

[IanH]

The intent of the LIB macro in the makefile appears to be for compiler flags that libraries require.  Ideally this intent would have been explained in a comment (or a more descriptive macro name).

nmake has a feature that environment variables automatically become macros, and if those macros are then redefined the environment variable is also changed for any invoked tasks. 

Given LIB has a rather different meaning as an environment variable for the standard windows linker, that's a poor choice of macro name within the makefile.  This poor choice on Windows might be because the makefile was written for use on a different operating system (suggested by the use of ".o" for object code), and/or a different make tool.

Rename the LIB macro to something reasonable like FORTRAN_COMPILER_FLAGS_FOR_LIBRARIES.  Future readers of the makefile will have less guessing to do about the intent of the macro, and if it happens to match an environment variable use by an invoked task, then that match is more likely to be meaningful.

[MWind2]

C:\Program Files (x86)\Intel\oneAPI\compiler\2023.1.0\windows\lib +x86 or x64, not like 2023.0.0 my mistake

[jimdempseyatthecove]

Forum moderator: GRIPE

This forum (thread) is displayed linearly, IOW .NOT. as a tree, yet you insert the comments/replies as if this were in tree format.

IOW, a preferred manner would be to display in chronological order .WITH. reference sequence number in the thread. e.g. #1, #2, #3, ...

The earlier forum did this, and this permitted:

a) scrolling the last page to the bottom to get the new comments (not requiring you to scan all pages for date/time)

b) writing a comment referencing more than one post

Jim Dempsey