Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
1 View

linker error misery

I'm trying to build an old console program, and I get about 1000 linker errors like the following:

Error 730  error LNK2019: unresolved external symbol _vsprintf referenced in function _for__io_return libifcoremt.lib(for_diags_intel.obj)

Error 572  error LNK2001: unresolved external symbol _memmove imsl.lib(crgrg.obj) 
 

Can anyone tell me what I'm doing wrong?
 

0 Kudos
28 Replies
Highlighted
Black Belt
1 View

Please show the command line

Please show the command line used at the link step (or the relevant lines in the VS build log). The indications are that the C run time library is not being searched, for some reason. One possibility is that a mixture of 32-bit and 64 bit objects is being fed to the linker.

 

0 Kudos
Highlighted
Beginner
1 View

build log is attached. 

build log is attached.  Everything seems to be built as 32 bit Debug.  There are three elements to the project.

One fortran console program xltorsion.exe

A small C lib that writes progress messages to the console window.

A small fortran DLL.

I have another very similar project that builds with no problem.  I have compared them very carefully and can't find anything different about the build settings.  I've got the following in the main program.

INCLUDE 'link_fnl_STATIC.h'

!DEC$ OBJCOMMENT LIB:'libiomp5md.lib'

0 Kudos
Highlighted
Black Belt
1 View

This line in the build log

This line in the build log tells us what is wrong:

Creating temporary file "RSP1.rsp" with contents
[
 /OUT:"Debug/XLTorsion.exe" /INCREMENTAL:NO /NOLOGO /NODEFAULTLIB:"libc" /NODEFAULTLIB:"libcmtd" /MANIFEST /MANIFESTFILE:"C:\Users\Brian\Documents\Visual Studio 2010\Projects\TRC-2013\Lateral Torsion Coupling\XLTorsion\Debug\XLTorsion.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"Debug/XLTorsion.pdb" /MAP /SUBSYSTEM:CONSOLE /STACK:500000000 /IMPLIB:"C:\Users\Brian\Documents\Visual Studio 2010\Projects\TRC-2013\Lateral Torsion Coupling\XLTorsion\Debug\XLTorsion.lib" /MACHINE:I386 "Debug/Security.obj" "Debug/DebugTools.obj" "Debug/Modules.obj" "Debug/TorInput.obj" "Debug/ForceResp.obj" "Debug/Spd Dependent.obj" "Debug/selmat.obj" "Debug/Damped.obj" "Debug/RK4.obj" "Debug/Conelem.obj" "Debug/UTF.obj" "Debug/Outputs.obj" "Debug/Main.obj" "Debug/AssembleMat.obj" "Debug/TorTransient.obj" "Debug/NewmarkBetaWilsonTheta.obj" "C:\Users\Brian\Documents\Visual Studio 2010\Projects\TRC-2013\Lateral Torsion Coupling\DLLUserTor\DLLUserTor\Debug\DLLUserTor.lib" "C:\Users\Brian\Documents\Visual Studio 2010\Projects\TRC-2013\Lateral Torsion Coupling\XLTorsion\Debug\XLTorsion_lib.lib" "C:\Users\Brian\Documents\Visual Studio 2010\Projects\TRC-2013\Lateral Torsion Coupling\XLTorsion\Code\KEY-LOK Security\KFUNC32.OBJ" "C:\Users\Brian\Documents\Visual Studio 2010\Projects\TRC-2013\Lateral Torsion Coupling\DLLUserTor\DLLUserTor\Debug\DLLUserTor.lib" "C:\Users\Brian\Documents\Visual Studio 2010\Projects\TRC-2013\Lateral Torsion Coupling\XLTorsion\Debug\XLTorsion_lib.lib"
]

Note that the C RTL is being explicitly ruled out. Linker options such as /nodefaultlib:libc are needed when there is a possibility of more than one version of the C RTL being used in a link job. What you need is that 1 (one, and only one) C RTL be used to link and build your EXE. You have to look at the various VS "project" settings to see why you ended up with specifying 0 (zero) versions of the C RTL instead.

0 Kudos
Highlighted
1 View

Change 'link_fnl_static.h' to

Change 'link_fnl_static.h' to 'link_fnl_shared.h'

Retired 12/31/2016
0 Kudos
Highlighted
Beginner
1 View

I changed Fortran/Libraries

I changed Fortran/Libraries from Debug Multithread to Debug Multithread DLL and it now builds and runs, but I do not understand why.

It did not seem to matter whether I used 'link_fnl_static.h' or 'link_fnl_shared.h'.

I'm relieved it's finally running, but I wish I knew why.

0 Kudos
Highlighted
1 View

It's a C thing, where the

It's a C thing, where the compiler generates different code when linking against shared vs. static libraries. Fortran doesn't do this.

Retired 12/31/2016
0 Kudos
Highlighted
Beginner
1 View

I would really like to get

I would really like to get rid of the C component of this project.  It only does one thing - repeatedly write progress messages to the console window on the same line by using printf().  I have read a couple of forum threads about doing this in fortran, which I think said it can be done easily enough, but is not "standard" fortran.

Unless you advise against it, I think I will go ahead and replace the C with fortran.

Thanks,

Brian

0 Kudos
Highlighted
1 View

If you can do what you want

If you can do what you want all in Fortran, that would be fine. There are various ways of writing progress messages, some more standard than others.

Retired 12/31/2016
0 Kudos
Highlighted
Beginner
1 View

I think I have successfully

I think I have successfully switched from C with prinft to Fortran with a $ sign as a format specifier.

Now that I've removed the C component from the project, I'm surprised that MSVCR100D.DLL still shows up in Dependency Walker.  Is there a way to identify why the console program depends on this?

The project has a setting of Linker/Input/Ignore Specific Libraries  libc; libcmtd  but I don't know why or what this does.  Trying to build w/o this gives an error of cannot open libc.lib.

I tested writing to the console window with a small test program, and that one doesn't have anything for Ignore Specific Libraries, and the .exe isn't dependent on any MSVCR DLL.

0 Kudos
Highlighted
Beginner
1 View

I should say that the code

I should say that the code that still shows the dependence on MSCVRT DLL's uses IMSL with the following lines in the main program.  Is this the reason for the dependence?

INCLUDE 'link_fnl_static.h'

!DEC$ OBJCOMMENT LIB:'libiomp5md.lib'

0 Kudos
Highlighted
1 View

libc,lib has not existed

libc,lib has not existed since VS2005. The linker setting is trying to avoid linking to variants of MSVC libraries that are incompatible with DLL linking. I would not expect a dependency on MSVCR100D.DLL unless you were building a Debug configuration using VS2010.  I still think you should use link_fnl_shared.h. (and then you don't need the OBJCOMMENT directive.)

Retired 12/31/2016
0 Kudos
Highlighted
Beginner
1 View

At the moment I am making a

At the moment I am making a debug build, and I am using VS2010.  My goal is build a single .exe without any dependencies on any DLL's other than one name DLLUserTor.DLL, which is unavoidable.  That DLL is just standard fortran with one exported routine called by the main program.

Later today or tomorrow I will try the things you suggested.  But I am stuck with VS2010.

Thanks,

Brian

0 Kudos
Highlighted
Black Belt
1 View

As a general guideline (i.e.

As a general guideline (i.e. without taking specific care to avoid issues), if you have multiple executable modules (the windows operating system term - EXE's and DLL's basically) in your process then you need to use a DLL variant of any runtime library that is common to those executable modules.  Otherwise you can end up with two instances of the runtime active in your process, and, without specific care, those instances can conflict at runtime over resources (memory, input/output aspects, exception handlers, thread control) that are inherently shared between them.

Recent compiler variants don't even provide static versions of the OMP runtime library as a consequence, because the inherently shared resources associated with the OMP runtime are very difficult to isolate.

 

0 Kudos
Highlighted
Beginner
1 View

The Release build doesn't

The Release build doesn't have any dependency on a MSVCR DLL.  So that's great.

But DWalker says there is a dependency on c:\program files (x86)\common files\intel\shared libraries\redist\intel64\compiler\LIBIOMP5MD.DLL

This is a 32 bit build. A dependency on 64 bit LIBIOMP5MD.DLL seems wrong?  Is this going to be a problem?

I would like to eliminate the dependency on LIBIOMP5MD.DLL altogether.  Is that possible?

0 Kudos
Highlighted
Black Belt
1 View

Dependency walker can get

Dependency walker can get confused when it encounters a DLL of the wrong bitness, ahead of a DLL of the relevant bitness in its search order.

As per the last paragraph of #14, if you use OpenMP with recent compilers you will always have a dependency on the OpenMP runtime DLL.

 

 

0 Kudos
Highlighted
Beginner
1 View

this old code doesn't need

this old code doesn't need MPI.  Fortran/Language/Process OpenMP Directives is set to  Generate Parallel Code (/Qopenmp)

I changed this to Disable and rebuilt, but DWalker still says  LIBIOMP5MD.DLL  is in the dependencies.

What is the right way to turn off MPI?

0 Kudos
Highlighted
Black Belt
1 View

LIBIOMP5MD.DLL is an OpenMP

LIBIOMP5MD.DLL is an OpenMP runtime DLL.
 

0 Kudos
Highlighted
Valued Contributor II
1 View

did you remove !DEC$

did you remove !DEC$ OBJCOMMENT LIB:'libiomp5md.lib'?

0 Kudos
Highlighted
Beginner
1 View

With !DEC$ OBJCOMMENT LIB:

With !DEC$ OBJCOMMENT LIB:'libiomp5md.lib' I get the dependency.

Without it I get 100+ linker errors like the following:

Error 159  error LNK2019: unresolved external symbol _omp_unset_nest_lock referenced in function _E1LOCK imsls_err.lib(e1lock.obj) 
 

0 Kudos