Error LNK2019: unresolved external symbol when using a module

[gib]

I am trying to compile a very simple program that uses a precompiled module (a module I use elsewhere). 

I have tried

ifort poisson.f90

and

ifort poisson.f90 par_zig_mod.obj  (the module is par_zig_mod)

but whatever I try I get the unresolved external symbol error.  In the other programs that use this module I build a VS2019 project, but now I am building a simple program at the command line.

(I suspect that I faced and solved this problem a few years ago, but now I can't recall the solution.)

[mecej4]

You have given a rather vague description, and I can think of several scenarios where one may run into an "unsatisfied external" error during building. I do not feel that it is worthwhile to speculate about those situations.

Presumably, you are in possession of a par_sig_mod.f90 source file. Did you compile that file first, and how?

What procedures and variables does it provide? Do you have a USE par_sig_mod statement in poisson.f90?

[gib]

Hi,

Yes, I have the source code, par_zig_mod.f90, and yes, in poisson.f90 I have 'use par_zig_mod'.

First I just copied par_zig_mod.mod and par_zig_mod.obj from where they are linked to another program that uses the module, and when that failed I copied the source file and compiled it with:

ifort /c par_zig_mod.f90

which creates the .mod and .obj files.

I try to compile poisson.f90 with

ifort poisson.f90 par_zig_mod.obj

or, having made poisson.obj, with

ifort poisson.obj par_zig_mod.obj.

The result in all cases is the same.

[gib]

Thanks to your questions I was prompted to try a different compile line, and now this works:

ifort par_zig_mod.obj poisson.f90 -o poisson.exe

It seems that the .obj file must precede the file with the code with the main program.  I didn't know this.

[mecej4]

No, your conclusion regarding the order of listing the OBJ files in the linking command is not correct. I routinely build programs using makefiles, and the linking command often contains "*.obj", which does not specify any order in which the OBJ files should be processed by the linker.

Please provide a test case with source files and command lines that will lead to the claimed "unsatisfied external" failure, and we can tell you what is happening.

[gib]

This is odd.  I haven't changed the code, but now I can compile with command lines that previously gave the LNK2019 error - as you say, the order doesn't matter. I can't get that error now whatever I do:

ifort poisson.f90 par_zig_mod.obj

ifort par_zig_mod.obj poisson.f90

ifort par_zig_mod.obj poisson.obj

ifort poisson.f90 par_zig_mod.f90

ifort par_zig_mod.f90 poisson.f90

all these work (provided I first compile par_zig_mod.f90 in the cases where I am just linking the .obj).

Another odd thing - now when I simply copy par_zig_mod.obj from where it has been compiled in the other program, if I try to compile with it I get a LNK4098 warning that "default lib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library", which I didn't get before.  It's not important, but /NODEFAULTLIB doesn't work at the command line, and I couldn't find out how to get this effect.  Since I can compile par_zig_mod.f90 afresh, this is a non-issue for me.

There doesn't seem much point in providing the code, since it is all working now, but I will provide a simplified test.f90 and the par_zig_mod code.

[mecej4]

Note that /NODEFAULTLIB is a linker option; to use it, either set the environment variable LINK to /NODEFAULTLIB:msvcrt.lib, use a command similar to

ifort poisson.f90 par_zig_mod.f90 /link /nodefaultlib:msvcrt.lib

There is a file called "ifort.cfg" in the compiler's bin directory; that file may be empty (zero length), or, as I do, you may place your preferred and consistently used options in that file. Visual Studio project files provide another place where these preferences may be specified.

Object files contain directives regarding which versions (static multithreaded, static single threaded or dynamic multithreaded) of the libraries to use. If you attempt to link files built with different library conventions, errors may occur or warning messages may be issued.

[gib]

Thanks.  I omitted the "/link".