MSVC tends to put those

Brian_Murphy · ‎02-01-2018

I have a console app I can build in Release mode with either Multithreaded or Multithreaded DLL options for Libraries. In Debug mode, I can build it with Multithreaded DLL, but not with Multithreaded because get over 1000 linker errors starting with the following:

Error 1324  error LNK2019: unresolved external symbol _vsprintf referenced in function _for__io_return libifcoremt.lib(for_diags_intel.obj) 
Error 1462  error LNK2019: unresolved external symbol _vsnprintf referenced in function ___libm_error_support libmmt.lib(libm_error.obj) 
Error 1305  error LNK2019: unresolved external symbol _toupper referenced in function _for_open libifcoremt.lib(for_open.obj) 
Error 1446  error LNK2019: unresolved external symbol _tolower referenced in function _for_check_env_name libifcoremt.lib(for_io_util.obj)

Is there something obvious I might be doing wrong?

Steve_Lionel · ‎02-01-2018

It's trying to find the Microsoft Visual C++ libraries and failing. Did you not get ANY other error messages (for example, missing libraries)? Please attach a ZIP of the buildlog.htm from a rebuild of the project, so we can see what is going on.

Brian_Murphy · ‎02-01-2018

I've attached the zipped buildlog.htm. Every error message is an unresolved external. I don't see the word "missing" anywhere in the build log. This console program links in routines via 4 LIB files from another project. I wonder if something is incompatible with the Visual Studio project settings for those and the console program I'm trying to build. However, in Release mode there is no trouble building with or without the DLL flag.

The project was made by others a long time ago. It has /Qopenmp set, I think because they were at one time dabbling with parallel processing, but I don't there is any of that in the current code. Is there a safe way to tell if this flag is needed?

Brian_Murphy · ‎02-01-2018

Oh boy! I tried fiddling with compiler settings, and now I can longer build successfully with the Multithreaded DLL option. I broke something, but I don't know what, and I can't get it back to building. I've attached the latest buildlog.htm. I hope you can tell where I screwed up.

Steve_Lionel · ‎02-01-2018

/NODEFAULTLIB:"libc" /NODEFAULTLIB:"Libcmtd"

Get rid of these.

Brian_Murphy · ‎02-01-2018

That helped. Reduced 2000+ linker errors down to 1.

Error 4 fatal error LNK1104: cannot open file 'LIBC.lib' LINK

Here are the compiler and linker command lines. LIBC.LIB is not there anywhere. Should it be? What is it for?

/nologo /debug:full /Od /I"Debug/" /I"C:\Users\Brian\Documents\Visual Studio 2010\Projects\TRC-2013\Lateral Torsion Coupling\ARPACK\SRC\Debug" /I"C:\Users\Brian\Documents\Visual Studio 2010\Projects\TRC-2013\Lateral Torsion Coupling\ARPACK\UTIL\Debug" /I"C:\Users\Brian\Documents\Visual Studio 2010\Projects\TRC-2013\Lateral Torsion Coupling\ARPACK\BLAS\Debug" /I"C:\Users\Brian\Documents\Visual Studio 2010\Projects\TRC-2013\Lateral Torsion Coupling\ARPACK\LAPACK\Debug" /I"C:\Users\Brian\Documents\Visual Studio 2010\Projects\TRC-2013\Lateral Torsion Coupling\DLLUser\Debug/" /DXLTRC_INTEL_VF /DxxxDEBUG_MODE_OVERRIDE_SECURITY_KEY /assume:nocc_omp /module:"Debug/" /object:"Debug/" /Fd"Debug\vc100.pdb" /traceback /check:pointer /check:bounds /check:uninit /check:format /check:output_conversion /check:stack /libs:dll /threads /c

/OUT:"Debug/XLTRC2.exe" /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:"C:\Users\Brian\Documents\Visual Studio 2010\Projects\TRC-2013\Lateral Torsion Coupling\XLTRC2\Debug\XLTRC2.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"Debug/XLTRC2.pdb" /MAP /SUBSYSTEM:CONSOLE /STACK:50000000 /IMPLIB:"C:\Users\Brian\Documents\Visual Studio 2010\Projects\TRC-2013\Lateral Torsion Coupling\XLTRC2\Debug\XLTRC2.lib"

Steve_Lionel · ‎02-01-2018

LIBC is the MSVC static library. It isn't used in newer MSVC versions, which have different library names. The lines you show in your latest post specify linking to DLL libraries, so I would not expect to see static libraries mentioned.

Are you linking in an object that was compiled with an old compiler (either Fortran or C/C++?) This might have a reference to libc in its linker directives (embedded in the object.) In this case it might actually make sense to put in libc.lib as a library to ignore and hope for the best.

Brian_Murphy · ‎02-01-2018

On my development system there are no files named libc.* and there never have been. So until I messed it up, the program was building without any such file.

As it stands right now, the program will build in Release mode but not in Debug mode. Yesterday Debug would at least build with the Multithreaded DLL option, but now it won't. I absolutely need to be able to build a Debug version. So I have a crisis on my hands.

I looked on another computer and found a LIBC.LIB dated 1995 in a set of Powerstation install files. I copied that to my development system and added it to the project. Now Debug will build and run. But this is crazy. It was building before without this file. The visual studio Project Dependencies thing lists 5 dependencies. All 5 are other fortran projects which are in the VS solution of which this console program is part of. There is one other LIB added to the project for the console program which is for a DLL from a security key vendor. I don't think there's any way the LIBC.LIB dependency came from that.

The only Properties/Fortran/Compatibility Powerstation setting set to YES is Use PowerStation Portability Library. But this seems to be the default since it doesn't appear in the compiler command line.

Will Dependency Walker be of any help here?

andrew_4619 · ‎02-02-2018

1] You seem to be linking with a number of non system libs, did you build these as well or are they built with an older compiler?

2] Check if there are any objcomment entries in your sources that pull in specific named libs.

mecej4 · ‎02-02-2018

Most probably, the dependency on the old LIBC.LIB was introduced through one of the OBJ or LIB files given to the linker, rather than through a command line option such as /MT or /libs:xxx . See this post about OBJCOMMENT: https://software.intel.com/en-us/node/679613 . See this about specifying library dependencies through pragmas in C/C++ sources: https://msdn.microsoft.com/en-us/library/7f0aews7.aspx . In this way, your using a Powerstation library may have created an unwanted dependency on LIBC.LIB.

In my experience, in such situations the solution is to use the linker option /NODEFAULTLIB to make the linker ignore unwanted dependencies on libraries such as LIBC.LIB.

Brian_Murphy · ‎02-02-2018

There is only one occurrence of OBJCOMMENT in the entire project. I think it is for IMSL purposes.

        INCLUDE 'link_fnl_STATIC.h'
        !DEC$ OBJCOMMENT LIB:'libiomp5md.lib'

I tried building with /NODEFAULTLIB, but that seemed to have no effect. I still get 1000+ unresolved externals without including LIBC.LIB in the project, and the project will not build at all with the Debug Multithreaded option.

As far as I can tell, all components that go into this console program are built in the VS solution, with the lone exception being a DLL from a security key vendor.

Will Dependency Walker be of any help here?

andrew_4619 · ‎02-02-2018

there are verbose options for the linker that shows what gets resolved from where over multiple passes. That will give some clues where things are pulled in

IanH · ‎02-02-2018

Dependency walker can be used to check dependencies between EXEs and DLLs, after they have been successfully built. Your issue is preventing you from a successful build.

You can use `dumpbin /directives` at the command prompt to examine directives within the library files and object files that you are trying to link together, for example:

>dumpbin /directives test.lib
Microsoft (R) COFF/PE Dumper Version 14.00.24215.1
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file test.lib

File Type: LIBRARY

   Linker Directives
   -----------------
   -defaultlib:ifconsol
   -defaultlib:libifcoremt
   -defaultlib:libifport
   -defaultlib:libmmt
   -defaultlib:LIBCMT
   -defaultlib:libirc
   -defaultlib:svml_dispmt
   -defaultlib:OLDNAMES

  Summary

          B9 .drectve
           C .pdata
           8 .rdata
          74 .text
          14 .xdata

You build log attached some posts above, which has the full effective linker command line, has a number of libraries in it that are in directories that suggest that they are not being rebuilt (unless you have changed directories for librarian output from their default). As others have suggested, I would have a close look at these libraries and object code.

"C:\Users\Brian\Documents\Visual Studio 2010\Projects\TRC-2013\Lateral Torsion Coupling\XLTRC2\Code\KEY-LOK Security\KFUNC32.OBJ" 
"C:\Users\Brian\Documents\Visual Studio 2010\Projects\TRC-2013\Lateral Torsion Coupling\XLTRC2\Code\LimeLM\x86\TurboActivate.lib" 
"C:\Users\Brian\Documents\Visual Studio 2010\Projects\TRC-2013\Lateral Torsion Coupling\XLTRC2\HYDROCOMP2.lib" 
"C:\Users\Brian\Documents\Visual Studio 2010\Projects\TRC-2013\Lateral Torsion Coupling\XLTRC2\HYDROCOMP1.lib"

Brian_Murphy · ‎02-02-2018

I tried /NODEFAULTLIB but got 1000+ linker errors when building with the Debug Multithreaded DLL option. When I take that out it will build, with or without LIBC.LIB added to the project. Still can't get it to build with the Debug Multithreaded option no matter what I do.

I added /VERBOSE, but that didn't tell me anything, but I don't know what to look for. The attached zip contains build logs for the good debug build (DLL) and the failed debug build (no DLL).

mecej4 · ‎02-03-2018

Each of the two build-log files in #14 show the problem. Line 365 of the "bad" and Line 4 of the "good" log contain the following item that is given to the linker.

Linking...
Creating temporary file "RSP1.rsp" with contents

...C:\Users\Brian\Documents\Visual Studio 2010\Projects\TRC-2013\Lateral Torsion Coupling\XLTRC2\LIBC.LIB...

In other words, something in your project is causing LIBC.LIB to be specified among the linker inputs. It is also unusual for you to have an obsolete CRT library in your own working directory and, worse, have that library as linker input and exclude needed CRT libraries (see below).

I suggest that you search within the project files (*proj*) to locate the line(s) that pull in LIBC.LIB, ascertain why that item is specified, and fix the problem in a suitable manner.

Here is a second problem for you to investigate and fix: the build logs show /DISALLOWLIB directives for LIBCD.LIB, LIBCMT.LIB, LIBCMTD.LIB and MSVCRT.LIB. It is these directives that, in combination with /NODEFAULTLIB:LIBC.LIB, leave the linker with not even one library that is a source of the needed CRT routines. Where did the /DISALLOWLIB directives come from?

Steve_Lionel · ‎02-03-2018

MSVC tends to put those /DISALLOWLIB directives in.

Brian_Murphy · ‎02-03-2018

Out of all the *proj* files, only the one for the console program contains any mention of LIBC, where the Release builds have /NODEFAULTLIB:"Libc" because someone, could have been Steve Lionel, told me years ago to put it in. I don't recall the details, but Release would not build without it. Today, however, I've broken it again and Release will not build with or without it.

My current situation is Release will not build at all (it used to). I can build Debug but only with the Debug Multithreaded DLL option.

Error 13 error LNK2005: _for_write_seq_xmit already defined in libifcoremd.lib(libifcoremd.dll) libifcoremt.lib(for_wseq.obj)

I'm willing to pay someone to fix it for me. Any takers?

FortranFan · ‎02-03-2018

Brian Murphy wrote:

.. Today, however, I've broken it again and Release will not build with or without it.

.. I'm willing to pay someone to fix it for me. Any takers?

Readers here can empathize with your struggles: in spite of all the verbiage online, working with Visual Studio (VS) can prove rather tricky, especially with mixed-language solutions.

Perhaps an alternate path you can take is start with a 'template' VS solution that contains suitable but empty projects such as C or C++ or Fortran static library projects, similarly some DLL projects, and one or more console (main program) projects. You can then simply 'add' your actual source code to them and see if you are able to build and execute/debug your code. Toward this, you will need to provide some details of your needs: how many console apps (is it just one?) and is it a Fortran main or C, C++? Do you need static library projects and if yes, which all languages? Same with DLL projects. Plus do you need to use OpenMP? How about IMSL? What other program requirements do you have?

But if you don't want to go through any further hassles and given your point about " Any takers?", sure I can try giving you a hand. If you can 'share' the information temporarily some place (drives on the cloud?) and provide contact details, I can reach out to you.

Brian_Murphy · ‎02-03-2018

Nevermind, I think. I started over from scratch in a new Visual Studio Solution, Copied all source code to new folders. Created a new vfproj for the main console program, and re-used the vfproj's for the 4 supporting LIB's and 1 supporting DLL. This is building both Release and Debug without any trouble so far, and BuildLogs show no presence of LIBC. Yippee!

FortranFan · ‎02-03-2018

Brian Murphy wrote:

Nevermind, I think. I started over from scratch in a new Visual Studio Solution.. Yippee!

Glad things seem to have worked out for you by starting over from scratch which is a variant of what I suggested to you in Quote #18.

Brian_Murphy · ‎02-03-2018

This console program is over 20 years old. Powerstation -> DEC -> Compaq -> Intel.

The project in it's current form is 100% fortran. Well, other than the Turboactivate.dll part which is probably C++ (that part was added very recently). At one time the project had a C component, but I replaced that with a Fortran equivalent. That may have caused the problems, but maybe not.

I've got lots more testing to do to confirm the new build is good.

building problems