IMSL 6.0 on Intel Visual Fortran 10.0.027 and VS2005

[klzhang]

We just got out IMSL 6 and IVF 10.

I installed IVF 10 and VS2005 on Windows XP 64bit computer. It works fine.

Then I installed the IMSL6 for IVF 10 and follow the instruction of UsingIMSL.pdf to configure the IMSL 6 for IVF.

After that, I tried to test whether it works or not.

I wrote a simple program as follows:

***********************************

program Console3
USE UMACH_INT
implicit none

integer NOUT

end program Console3
***********************************

I compiled and no error both in 32bit and x64bit building process.

However, when I call the UMACH function as follow:

***********************************

program Console3
USE UMACH_INT
implicit none

integer NOUT

CALL UMACH(2,NOUT)

end program Console3

***********************************

Error messages are as follows:

1>------ Build started: Project: Console3, Configuration: Debug x64 ------
1>Linking...
1>Console3.obj : error LNK2019: unresolved external symbol UMACH referenced in function MAIN__
1>x64DebugConsole3.exe : fatal error LNK1120: 1 unresolved externals
1>
1>Build log written to "file://C:UsersSourcecodesConsole3Console3x64DebugBuildLog.htm"
1>Console3 - 2 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

I really need help on this points. I tried every kinds of metheds and no help.

I used IMSL 5 with IVF 9, and other previous versions, all were fine. But this time, it is a little trouble.

Thanks for your kind help!

Kuilin

[Steven_L_Intel1]

You also need to add an include line such as:

INCLUDE 'link_fnl_static.h'

in order to pull in the proper libraries. The first test case didn't actually call anything so it linked ok.

[klzhang]

Dear Steve,

Thanks for reply.

I add the include part as you provide.

Now the program is as follows:

************************************

program Console3
INCLUDE 'link_fnl_static.h'
USE UMACH_INT

implicit none

integer NOUT
CALL UMACH(2,NOUT)

end program Console3
************************************

And the error messages are as follows:

1>------ Build started: Project: Console3, Configuration: Debug x64 ------
1>Linking...
1>imsls_err.lib(umach.obj) : error LNK2019: unresolved external symbol __kmpc_global_thread_num referenced in function UMACH
1>imsls_err.lib(e1lock.obj) : error LNK2001: unresolved external symbol __kmpc_global_thread_num
1>imsls_err.lib(umach.obj) : error LNK2019: unresolved external symbol __kmpc_threadprivate_cached referenced in function UMACH
1>imsls_err.lib(e1lock.obj) : error LNK2019: unresolved external symbol __kmpc_critical referenced in function E1LOCK
1>imsls_err.lib(e1lock.obj) : error LNK2019: unresolved external symbol __kmpc_flush referenced in function E1LOCK
1>imsls_err.lib(e1lock.obj) : error LNK2019: unresolved external symbol __kmpc_end_critical referenced in function E1LOCK
1>imsls_err.lib(e1lock.obj) : error LNK2019: unresolved external symbol __kmpc_set_nest_lock referenced in function E1LOCK
1>imsls_err.lib(e1lock.obj) : error LNK2019: unresolved external symbol omp_set_nest_lock referenced in function E1LOCK
1>imsls_err.lib(e1lock.obj) : error LNK2019: unresolved external symbol __kmpc_unset_nest_lock referenced in function E1LOCK
1>imsls_err.lib(e1lock.obj) : error LNK2019: unresolved external symbol omp_unset_nest_lock referenced in function E1LOCK
1>imsls_err.lib(e1lock.obj) : error LNK2019: unresolved external symbol __kmpc_init_nest_lock referenced in function E1LOCK
1>imsls_err.lib(e1lock.obj) : error LNK2019: unresolved external symbol omp_init_nest_lock referenced in function E1LOCK
1>x64DebugConsole3.exe : fatal error LNK1120: 11 unresolved externals
1>
1>Build log written to "file://C:UsersSourcecodesConsole3Console3x64DebugBuildLog.htm"
1>Console3 - 13 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

I did add the the path to the directory list at Tools->Options->Intel Fortran->General.

for Libraries:

C:Program Files (x86)VNIimslfnl600Intel64lib

for Includes:

C:Program Files (x86)VNIimslfnl600Intel64includedll
C:Program Files (x86)VNIimslfnl600Intel64includestatic

Thanks for your kind time and help!

Kuilin

[Steven_L_Intel1]

In IMSL 6.0 they added the requirement that the thread libraries be linked against. VNI says to use /Qopenmp for this purpose, but that has additional effects that you may not want.

Add this line after the INCLUDE:

!DEC$ OBJCOMMENT LIB:"libguide.lib"

and that should do it. I'm trying to convince VNI that they should add libguide (or libguide40.lib as appropriate) to the link_fnl_xxx files.

[klzhang]

Hi Steve,

Thank you very much! You are really help at this point, which costed me two weeks and no solution.

Yes, I enabled the /Qopenmp at the project properties->Language->Process OpenMP Directives. But it needs that line you provide only once.

Anyway, please give us an new release about this in the near future, so that we can use IMSL and OpenMP with Intel Visual Fortran in VS 2005 very well.

Thanks,

Kuilin

[Steven_L_Intel1]

If you enabled OpenMP you should not need the OBJCOMMENT directive as the compiler will reference that library by default.

Next time you get stuck, ask here or at Intel Premier Support. We'll be glad to help.

[fatalme]

This information is really useful. When I use IMSL, I havethe same problem.Will a revised vision of the IMSL lib come out?

[Steven_L_Intel1]

If you are referring to the requirement for libguide.lib or /Qopenmp, that is by design and not a bug. IMSL 6.0 is thread-safe and uses OpenMP features for that purpose. This creates the requirement for the OpenMP libraries.

[sculy]

I have the same compile problems, and they went away when I added the following lines to my DLL code:

INCLUDE 'link_fnl_static.h'
!DEC$ OBJCOMMENT LIB:"libguide.lib"

(thanks much!)

However, now I have a new problem: when I try to run my application, I get the following error message:

OMP abort: Initializing libguide.lib, but found libguide.lib already initialized.
This may cause performance degradation and correctness issues.
Set environment variable KMP_DUPLICATE_LIB_OK=TRUE to ignore this problem and force the problem to continue anyway.
Please note that the use of KMP_DUPLICATE_LIB_OK is unsupported and using it may cause undefined behavior.
For more information, please contact Intel Premier Support.

Here's the background:

My application is written in C++, and it loads (dynamically) 3 different DLLs that are written in FORTRAN. Each of these three FORTRAN DLLs has static links to IMSL. I'm using Visual Fortran 10.1.011 and IMSL 6.0.

I'd prefer NOT to set the environment variable if possible. Is there another way to fix the compilation problems?

[Steven_L_Intel1]

You must use the DLL libraries in this situation, otherwise you have multiple copies of the OpenMP code in use. Change the Fortrran project propertues to specify "Multithread DLL" and replace the lines you added with:

INCLUDE 'link_fnl_shared.h'

You don't need the OBJCOMMENT line.

[sculy]

I don't want to appear ungrateful, but sharing the libraries probably won't work in this case. Long term, the DLLs will be built by different customers, with different code management and migration paths. For instance, they might not even be built with the same versions of Visual Fortran and/or IMSL. Carrying around multiple copies of the OpenMP code is not really an issue here (DLLs are loaded dynamically), and is probably preferred.

This worked in a previous incarnation of VF and IMSL. I'm just the guy who got tagged with migrating to the latest version :^). Disabling OpenMP might be an option, but long term we want to use that, too.

Best regards,
Steve Culy
GoldSim Technology Group
www.goldsim.com

[Steven_L_Intel1]

Sorry, but you don't have a choice. Previous versions of IMSL did not use OpenMP, version 6 does. There's no way to turn it off. It does not matter what your code does. You will need to tell the end users to link the DLLs shared, and the instructions for that vary depending on IMSL version. I assume that you provide build instructions or scripts.

[sculy]

OK. Thanks for the quick and honest responses (even though it's not what I wanted to hear :^). I guess that we will have to fall back to using the environment variable KMP_DUPLICATE_LIB_OK=TRUE, and hope that it doesn't cause any problems.

Thanks again,
Steve