IMSL6.0 -- include 'link_fnl_shared.h' statement must be in the module's specification part

[asymptotic]

Hello every one, I am wondering why the IMSL6.0'link_fnl_shared.h' statement must be in the module's specification part, can't in the module procedure's specification part?
(Win7-64bit + IVF11.1.067 + IMSL6.0, Configuration Win32)

Module IMSL_BSJYIK0

! IMSL6.0, Configuration Win32

include 'link_fnl_shared.h' ! right

contains

subroutine Test_BSJ0

! include 'link_fnl_shared.h' ! error, in here

use BSJ0_INT

implicit none

real:: x, y

x = 3.0

write(unit = *, fmt = *) "BSJ0 function --- "

y = BSJ0(x)

write(unit = *, fmt = *) x, y

return

end subroutine

End Module

[mecej4]

If link_fnl_shared.h contains just an OBJCOMMENT directive, as in other versions of IMSL, either location should be OK.

In fact, even with the INCLUDE statements removed it should work, if you use the %LINK_F90% argument to the compilation command.

Please display the error messages that you received.

[asymptotic]

If 'link_fnl_shared.h' statement appear in the module's specification part, the compiler give the following error:
unresolved external symbol _S_BSJ0 referenced in function _IMSL_BSJYIK0_mp_TEST_BSJ0

(Win7-64bit + Microsoft Visual Studio 2008 + IVF11.1.067 + IMSL6.0, Configuration Win32)
Icompile the above source codeinIDE, not in command line.

Thanks a lot.

[mecej4]

I am not familiar with the integration of IMSL into the IDE (if any), but you probably need to specify in the project settings that IMSL is required, or you may specify imsl_dll.lib as an additional library to search.

[Martyn_C_Intel]

It's a bit more than that. See the article at http://software.intel.com/en-us/articles/installing-and-using-the-imsl-libraries/ .
You need toset up the IMSL paths correctly, but the include file gives the OBJCOMMENT directive that codes into the object which libraries to link, so you don't need to specify them in the IDE.
Assuming you've done all that, I don't immediately see why it should make a difference whether the INCLUDE file is in a contained subroutine or not, (though I'm more used to seeing it at the head of a main program). We'll take a look.

[Martyn_C_Intel]

The developer with whom I talked also couldn't immediately think of a reason why the directive shouldn't work within a contained subroutine. I will submit a request for such directives to be accepted. Even if there are no further obstacles, it will likely be quite some time before that shows up in a new compiler version, though.
Thanks for the report!

[mecej4]

I do not observe a compiler error message or a linker error message when the include 'link_fnl_shared.h' statement appears in either, both or none of the two locations shown in the original post, or in a main program that calls Test_BSJ0, as long as I specify the %LINK_F90% option.

In my version of IMSL, which was not obtained bundled with the Intel compiler, the included file contains the single line

!dec$objcomment lib:'imsl_dll.lib'

As one would expect, if I compile without the %LINK_F90% option added to the compiler command, I get an unsatisfied reference to _S_BSJ0, unless there is at least one active INCLUDE line.

[Martyn_C_Intel]

Right, putting one of the LINK_.... environment variables on the link lineis an equally goodway of specifying which libraries to link. The LINK... include files have the effect of embedding the libraries needed for linking into the source and object files, which may or may not be a good thing, depending on your context.

[Martyn_C_Intel]

A change to support the OBJCOMMENT directive within a contained subroutine has been made, and will appear in the next major compiler version.

[Martyn_C_Intel]

Support for the OBJCOMMENT directive within contained subroutines is implemented in the version 13.1 and 14.0 compilers.