LIBCMT.LIB external symbol error

[Alison_B_]

Hi

I am compiling and linking code developed by another source. They have recently changed to using Fortran 11.1 so we are using the trial version of that compiler (previously using 9.1).

can you suggest the cause of the following errors?

libifcoremt.lib(for_init.obj) : error LNK2001: unresolved external symbol __imp_GetModuleHandleA
libifcoremt.lib(for_aio.obj) : error LNK2001: unresolved external symbol __imp_GetModuleHandleA
libifcoremt.lib(for_exit_handler.obj) : error LNK2001: unresolved external symbol __imp_GetModuleHandleA
libifcoremt.lib(for_diags_intel.obj) : error LNK2019: unresolved external symbol __imp_CreateFileA referenced in function for__dump_msg_buff
libifcoremt.lib(for_nt_open_proc.obj) : error LNK2001: unresolved external symbol __imp_CreateFileA
LIBCMT.lib(open.obj) : error LNK2001: unresolved external symbol __imp_CreateFileA
LIBCMT.lib(initcon.obj) : error LNK2001: unresolved external symbol __imp_CreateFileA
libifcoremt.lib(for_init.obj) : error LNK2019: unresolved external symbol __imp_SetErrorMode referenced in function for_rtl_init_wrap_
libifcoremt.lib(for_init.obj) : error LNK2019: unresolved external symbol __imp_GetCommandLineA referenced in function for_rtl_init_wrap_
LIBCMT.lib(crt0.obj) : error LNK2001: unresolved external symbol __imp_GetCommandLineA
libifcoremt.lib(for_init.obj) : error LNK2019: unresolved external symbol __imp_GetACP referenced in function for_rtl_init_wrap_
LIBCMT.lib(mbctype.obj) : error LNK2001: unresolved external symbol __imp_GetACP
LIBCMT.lib(getqloc.obj) : error LNK2001: unresolved external symbol __imp_GetACP
libifcoremt.lib(for_init.obj) : error LNK2019: unresolved external symbol __imp_SetConsoleCtrlHandler referenced in function for_rtl_init_wrap_
LIBCMT.lib(winsig.obj) : error LNK2001: unresolved external symbol __imp_SetConsoleCtrlHandler
libifcoremt.lib(for_aio.obj) : error LNK2019: unresolved external symbol __imp_DeleteCriticalSection referenced in function for__aio_destroy
LIBCMT.lib(mlock.obj) : error LNK2001: unresolved external symbol __imp_DeleteCriticalSection
LIBCMT.lib(ioinit.obj) : error LNK2001: unresolved external symbol __imp_DeleteCriticalSection
LIBCMT.lib(closeall.obj) : error LNK2001: unresolved external symbol __imp_DeleteCriticalSection
libifcoremt.lib(for_aio.obj) : error LNK2019: unresolved external symbol __imp_InitializeCriticalSection referenced in function for__aio_acquire_lun_fname

Many more of the same type

thanks

Alison

[Steven_L_Intel1]

These are all references to Windows API routines defined in kernel32.lib. Usually this is linked in by default - how are you building the program? Command line or Visual Studio? Can you attach a ZIP of the build log (buildlog.htm if using VS, or the commands used to build from the command line)? You may just need to add kernel32.lib to the link inputs.

[Alison_B_]

I used shell command program developed by others. have attached some files that might answer your

See nemsh.sh

nfort.sh used to compile to obj files, not sure about ifort64X64.sh

the nems.sh.out.tracy... contains the command line output from the compiling/linking (where i pulled the error list from)

thanks

Alison

[Steven_L_Intel1]

This is sort of hard to follow, and I don't see the actual ifort command used for compiling (or linking). I see there are many other link errors from your application code, but you didn't ask about those...

The simple fix is to add "kernel32.lib" to whatever command is doing the linking. I couldn't spot that here. I am uncomfortable with the script that tries to emulate ifortvars.bat but that doesn't seem to be a problem.

See what you get with this fix and let us know. For what it's worth, I'd have expected the same problems with an older Fortran compiler.

[Alison_B_]

so i changed the nemssh.shell file from:

  XPRESSDIR="c:\\xpressmp64"; export XPRESSDIR
  LIB="c:\\xpressmp64\\lib;c:\\xpressmp64\\bin;$LIB"
  OMLLIBS=" OMLDB64.LIB OMLLIB64.LIB OMLLP64.LIB OMLWIN64.LIB OMLXPRS64.LIB xprs.lib"

TO

  XPRESSDIR="c:\\xpressmp64"; export XPRESSDIR
  LIB="c:\\xpressmp64\\lib;c:\\xpressmp64\\bin;$LIB"
  OMLLIBS=" OMLDB64.LIB OMLLIB64.LIB OMLLP64.LIB OMLWIN64.LIB OMLXPRS64.LIB xprs.lib kernel32.lib"

But no change in error messages, that I could see. Plus the scripts had been creating exe files before (able to compile and link) using Fortran 9.1 - then running into errors. The new version seems to lead to these linking errors that we didn't have before. I only pasted a short version of the many errors into the message since they seemed to have lots of repetition. Maybe you can identify the main errors to be concerned about from the output file that I had sent.

One question, we are using the "30 day trial version" of the fortran compiler. Are there any lib files that do not come with the trial version that might be leading to errors?

thanks

alison

[Steven_L_Intel1]

No, there's nothing missing from the trial version other than Visual Studio Shell. It could be that the newer libraries are referencing additional Windows API routines.

Would you please add /verbose:libs to the link options and attach a zip of the output? I am not sure what you are using to link.

What did you install to supply the Microsoft tools and libraries? Do you have a version of Visual Studio installed? If Windows SDK, which version?

[Alison_B_]

OK - I made the changes to the xilink line in the shell

xilink /out:nems.exe /incremental:no  /debug /map:nems.map /FORCE /NODEFAULTLIB:"libc.lib" /DELAYLOAD:"aimmslink.dll" /verbose:libs @nems.objs $OMLLIBS aimmslink64.lib delayimp64.lib kernel32.lib
    xilink /out:intercv.exe /incremental:no /debug /FORCE /NODEFAULTLIB:"libc.lib" /DELAYLOAD:"aimmslink.dll" /verbose:libs @intercv.objs aimmslink64.lib delayimp64.lib kernel32.lib
    xilink /out:tfiler.exe /incremental:no /debug /map:tfiler.map /FORCE /NODEFAULTLIB:"libc.lib" /DELAYLOAD:"aimmslink.dll" /verbose:libs @tfiler.objs aimmslink64.lib delayimp64.lib kernel32.lib

[JVanB]

Maybe the directory for kernel32.ib isn't known at the link step. Search your hard drive for kernel32.lib and include the appropriate directory in the LIB= line above. Note that you will find at least two: one for x86 and one for x64.

[Alison_B_]

The directory was long and complicated and I wasn’t sure how to translate windows into the shell language for long folder names with spaces…

So I copied kernel32.lib (from the x64 folder) to the folder where the other LIB files were … but no luck.

Do you think I should still try the LIB= thing or would copying the file to a known spot do the same thing?

thanks

[Steven_L_Intel1]

Sorry - that should have been /verbose:lib - no s on the end. Please try again.

[Alison_B_]

OK - here it is - would the search in C++ directory be the issue?

[mecej4]

I am not sure if this is the reason, but it should be easy to check if it is:

Near the top of the linker output in #11, I see " Searching C:\Program Files (x86)\Microsoft Visual C++ Toolkit 2003\lib\kernel32.lib". That is probably a 32-bit library, and the linker should have been told to use "C:\Program Files (x86)\Microsoft Visual C++ Toolkit 2003\lib\x64\kernel32.lib". Do you have the ..\lib\x64 subdirectory?

[Alison_B_]

I don't have that subdirectory in "program files" tree...

Under Users/../Visual Studio/documents I have

test1/test1/x64

and

lib1/lib1/x64

[mecej4]

It is possible that you have only a 32 bit Microsoft SDK installed, or that the SDK is damaged. You can check in the start menu or the AppWiz control panel to see details about the versions of the SDK(s) installed on your system. Can you build a simple 64 bit C program on your system? That is, do you have all the components (C compiler, tools and libraries) to make that work?

I don't think that there is anything to see in \Users\... for the present purposes.

[Alison_B_]

hmm.. that seems beyond what i can readily do but I will pass this along to our consultant who can. Do you have any suggested next steps assuming that I could create a simple 64 bit C program?

thanks for your help!
 

[mecej4]

I actually hoped that your attempt to build and run a C program would fail, since I know what to prescribe in that case!

The explanation is simple. Intel Fortran uses a number of build tools that are supplied with MS C/C++. Therefore, if a C build fails, there is a good chance that fixing this issue would also fix related Fortran build issues. Along the same lines, you can try building a 64-bit EXE in an IFort command window using a simple console program source.

You are making heavy use of Unix shell scripts. What environment do you have on Windows to support running those scripts?

[Alison_B_]

yes the code and scripts are provided by others.

we use MKS toolkit, korn shell for running these

[Brooks_Van_Horn]

Alison,

I may be wrong but I believe if you just included  -luser32 -lgdi32  libs from the Windows dll folder rhwen your link will find the external references.

Brooks Van Horn

[Steven_L_Intel1]

That "Microsoft Visual C++ Toolkit 2003" is very likely to be at least part of the problem.  There was probably no x64 library in that version, as x64 support didn't appear until VS2005. You shouldn't even have that folder in the libraries search list. My guess is that this is a very old install and it is still defined in the LIB system environment variable and messing up the links.

Please show us the output of the following.

Click on the Start button and type "cmd.exe" (no quotes) into the search box - click on it when it appears. Type:

cd \
set lib > lib.txt

Show the contents of lib.txt in C:\ (you can "cd" to a different place if you prefer.)

In Visual Studio, select Tools > Options > Intel Visual Fortran > Compilers. Click on the ... next to Libraries. Copy the contents and paste it here.

[Alison_B_]

steve

I tried those steps but failed

the set lib >lib.txt returned "access denied"

in Visual Studio, I found Tools > options ... but Fortran was not listed there (C++ was and other options just no Fortran)

We are trying to order Fortran 11.1 - hoping that install will help

Alison
 

[Steven_L_Intel1]

You don't have permission to write to C: then - cd to some folder you do have write permission for.

You cannot "order" 11.1. When you have bought a newer version, you can download and install older versions. That you are adding a layer of Linux shell complexity over this doesn't help things. It can be made to work, but we're a bit in the dark about how all the shell scripts are acting.