undefined references for static library and shared modules

[Michael_B_10]

We are having issues on windows 7 visual studio 2012/2013, using the intel compiler version 15.
Package ID: w_ccompxe_2015.2.179 w_fcompxe_2015.2.179 w_compxe_2015.2.179w_mkl_p_11.2.2.179

This package contains:
       Intel(R) Math Kernel Library 11.2 Update 2 for Windows*

We are building both a shared and static library composed of D.F90, D_gen.F90
and H.gen.
We then link this library with the main.F90 both statically and shared and
with static or shared modules.

The following combinations work:
1. Shared library with shared modules.
2. Shared library with static modules.
3. Static library with static modules.

BUT, Static library with shared modules fail to link with undefined references.

I've attached the entire build for a simple example which displays the issue, the actual source with the cmake build is in libex/libex.

Also, It works fine all combinations for Intel compilers on linux.

Any help would be appreciated.

Thanks,
Scot

[Kevin_D_Intel]

I'll take a look at this Scot.

[Kevin_D_Intel]

Just a brief update. I have finally been able to reproduce the link errors. The required setup was rather extensive but I'm over that hurdle at least. I'll let you know when I know more.

[Kevin_D_Intel]

The root cause of the unresolved externals relates to a difference in the .mod file produced when the ATTRIBUTES EXPORT directive is active/inactive per the BUILD_DLL predefine.

I do not know what that difference is yet since I don’t have a .mod file analyzer but I can see a subtle difference (in the octal dump) between the .mod file produced when the ATTRIBUTES EXPORT directive is active versus inactive. That difference results in the unresolved externals when compiling your main against the .mod from the flib-DLL build, but linking with the flib-static library.

Briefly, this doesn’t expose itself on Linux since the attribute would not be active between a static (.a) and shared lib (.so) build of flib and so there is no .mod file difference.

While I am waiting for Development’s insight, can I ask a question:  Did you experience the unresolved external link failures because your build infrastructure deposits .mod files for the flib-static and flb-DLL builds into a common area?

[Michael_B_10]

Kevin Davis (Intel) wrote:

While I am waiting for Development’s insight, can I ask a question:  Did you experience the unresolved external link failures because your build infrastructure deposits .mod files for the flib-static and flb-DLL builds into a common area?

We build the shared and static libraries in separate directories, include the module files, the problem is when we package the binaries we want to only include one version of the modules (in the include directory). We are working on releasing dual binaries of our library, so this is now an issue.

[Kevin_D_Intel]

Development confirmed the .mod files need to be different; commenting further that “The difference is that the mod files have the representation for D_api_3 and D_api_4 marked with DLL exported.   This is an attribute that is carried into any use of the module with the declarations for these routines.”

Releasing both versions of the lib requires providing the appropriate .mod files for each build.

[Michael_B_10]

That's a bummer, I guess we will have to keep around both sets of modules. Sometimes modules are very annoying to deal with!

Thanks for taking the time to look into it. On a related note, are you also able to reproduce the problem that I had noted in:

https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/591870

Thanks.

[Kevin_D_Intel]

I'm sorry I have not had time to look at the other thread. If there are any remaining questions following IanH's analysis/explanation then please let us know in that post.

PS - Thank you IanH for your assist with that other post.