Trouble configuring Fortran with FlexLM licensing

[tsmithapp-geo-resear]

We have a Fortran applicaton and want to control access with FlexLM feature keys. FlexLMlibraries are
written in "C" and with the calling convention"cdecl". After having tried all the mixed language examples, we cant seem to link the FlexLM libs with the Fortran app. We have tried wrapping the functions to override the calling convention
to "stdcall", we've tried overriding the calling conventionusing the Fortran interface method and we've tried different run time library options; usng DLL's instead of static libs etc. The FlexLM vendor has tried to help but does not have Fortran specific examples and no Fortran expertise on staff andclaim to have very few Fortran clients, so they have nothing concrete to share. Does anyone have examples on how to configure a Fortran app to use FlexLM "feature keys"?

[Steven_L_Intel1]

I've written Fortran code to call FlexLM - it isn't difficult, though as no Fortran include files are provided for the various declarations, you have to roll your own. First, which compiler are you using? Second, what is the nature of the problem you have? "can't seem to link" covers a rather broad range of possible errors. Please show the actual link errors and provide the C declaration of the routine you want to call.

[tsmithapp-geo-resear]

Quoting - Steve Lionel (Intel)

I've written Fortran code to call FlexLM - it isn't difficult, though as no Fortran include files are provided for the various declarations, you have to roll your own. First, which compiler are you using? Second, what is the nature of the problem you have? "can't seem to link" covers a rather broad range of possible errors. Please show the actual link errors and provide the C declaration of the routine you want to call.

Thank you for the prompt response, I am using compiler v11.0. My immediate problem is
simply to get Fortran to recognize (resolve) the FlexLM functions such as "lc_new_job".

Because of a complex FlexLM data structure called LM_HANDLE, and lacking an example, I chose to deal
with FlexLM in "C" code. So from Fortran I call a "C" library which in
turn handles all the "lc_*" details such as lc_checkout, lc_checkin etc.

In my current iteration I have the Fortran calling a "C" static lib with the
only one function of mine called "initialize". I can link and run with MY "C" "initialize" just fine as long as I
don't call on any FlexLM functions.

When I call my initialize WITH FlexLM calls I get the following:

1>FlexD.lib(FlexDll.obj) : error LNK2019: unresolved external symbol _lc_set_attr referenced in function _initialize@0
1>FlexD.lib(FlexDll.obj) : error LNK2019: unresolved external symbol _lc_get_errno referenced in function _initialize@0
1>FlexD.lib(FlexDll.obj) : error LNK2019: unresolved external symbol _lc_perror referenced in function _initialize@0
1>FlexD.lib(FlexDll.obj) : error LNK2019: unresolved external symbol _lc_new_job referenced in function _initialize@0

As I understand there are several reasons that can cause this such calling conventions,
run time library types, underscores, function arguments, I've tried many options and have
now expired my (admittedly feeble) knowledge in this area.

[Steven_L_Intel1]

I suppose the first thing is to make sure that you are linking in the FlexLM library that defines these symbols. How have you specified that? To get a list of the names defined by the FlexLM library, you can issue the following command from a Fortran Build Environment window:

dumpbin -symbols somelib.lib > somelib.txt

somelib.txt will then contain the output. Let me suggest that you remove any options you specified to change calling conventions as these will just get in your way.

Can you show me the part of the C header that defines, say, lc_new_job? I no longer have these sources handy.

[tsmithapp-geo-resear]

Quoting - Steve Lionel (Intel)

I suppose the first thing is to make sure that you are linking in the FlexLM library that defines these symbols. How have you specified that? To get a list of the names defined by the FlexLM library, you can issue the following command from a Fortran Build Environment window:

dumpbin -symbols somelib.lib > somelib.txt

somelib.txt will then contain the output. Let me suggest that you remove any options you specified to change calling conventions as these will just get in your way.

Can you show me the part of the C header that defines, say, lc_new_job? I no longer have these sources handy.

Following your instructions I am much closer to a solution. You were right, I found that in my current iteration my FlexLM libs were not defined under "Additional Dependencies". Thats bad, sorry for that. They are all there now.
I was doing too much thrashing around with different attempts and dropped that along the way somehow.


I find the my C Lib still needs to be compiled with the a Calling Convention of stdcall
otherwise I get a lot of unresolved errors when I link it to the Fortran "driver".
Here are two examples:

1>FlexD.lib(flex_utils.obj) : error LNK2019: unresolved external symbol __imp__RegSetValueExA@24 referenced in function _h0eKlir1dNHTNWIIG
1>FlexD.lib(flex_utils.obj) : error LNK2019: unresolved external symbol __imp__RegSetValueExW@24 referenced in function _vyXeFmm_ZdbPUA9MP

So I reset to my c lib's calling convention to stdcall, then rebuild the Fortan (either stdcall or c/ref)
and get these final errors either way:




1>FortranLBridgeDriver.obj : error LNK2019: unresolved external symbol _Initialize referenced in function _MAIN__
1>libifcoremt.lib(for_diags_intel.obj) : error LNK2019: unresolved external symbol __iob referenced in function _for__io_return
1>libifcoremt.lib(for_nt_open_proc.obj) : error LNK2001: unresolved external symbol __iob
1>libifcoremt.lib(for_init.obj) : error LNK2019: unresolved external symbol ___argv referenced in function _for_rtl_init_
1>libifcoremt.lib(for_init.obj) : error LNK2019: unresolved external symbol ___argc referenced in function _for_rtl_init_
1>C:AGR_DEV_LICCodeTestFDriverFDriverDebugfdrive.exe : fatal error LNK1120: 4 unresolved externals


= = =
You see MY "C" Initialize function is unresolved and then there is some Fortran unresolved.

=====================================================
This is all there is to my Fortran:

program FortranLBridgeDriver

implicit none

INTERFACE

!same error whether or not I use this interface
SUBROUTINE Initialize()
!DEC$ ATTRIBUTES :: Initialize
END SUBROUTINE Initialize

END INTERFACE

! Variables

CALL Initialize()

! Body of FortranLBridgeDriver
WRITE (*,*) 'Hello World'
end program FortranLBridgeDriver

========================
And this is all there is to the C program
========================

#include "lmclient.h"
#include "lm_attr.h"

static VENDORCODE code;
static LM_HANDLE *lm_job;

#include "FlexDll.h" // Only for C Driver tests


int Initialize()

{

int stat = 0;


if (lc_new_job(NULL, lc_new_job_arg2, &code, &lm_job))
{
lc_perror(lm_job, "lc_new_job failed");
return (lc_get_errno(lm_job));
}

lc_set_attr(lm_job, LM_A_LICENSE_DEFAULT, (LM_A_VAL_TYPE)".;@localhost");
lc_set_attr(lm_job, LM_A_LONG_ERRMSG, (LM_A_VAL_TYPE)0);

return ERROR_SUCCESS;

}

[Steven_L_Intel1]

First, the unresolved references to _RegSetValueExA@24, etc., are caused by your not adding advapi32.lib to the list of "Additional Dependencies". It has nothing to do with calling conventions. Please do not use stdcall unless you absolutely know you need it.

The second set of errors are mostly caused by the infamous "Mixed C Library Syndrome". Visual C++ defaults to using the Multithread DLL Debug libraries, but IVF defaults to the Multithread (Static) Debug libraries. Change one or the other to match. In C, it's under Code Generation, in Fortran, Libraries.

I am puzzled by the link error for _Initialize unless you have also set /names:as_is. If so, please remove it. Then replace this code:

[plain]INTERFACE

!same error whether or not I use this interface
SUBROUTINE Initialize()
!DEC$ ATTRIBUTES :: Initialize
END SUBROUTINE Initialize

END INTERFACE[/plain]

with this:

[cpp]INTERFACE

SUBROUTINE Initialize() BIND(C,NAME="Initialize")
END SUBROUTINE Initialize

END INTERFACE[/cpp]

See where that gets you.

[tsmithapp-geo-resear]

Quoting - Steve Lionel (Intel)

First, the unresolved references to _RegSetValueExA@24, etc., are caused by your not adding advapi32.lib to the list of "Additional Dependencies". It has nothing to do with calling conventions. Please do not use stdcall unless you absolutely know you need it.

The second set of errors are mostly caused by the infamous "Mixed C Library Syndrome". Visual C++ defaults to using the Multithread DLL Debug libraries, but IVF defaults to the Multithread (Static) Debug libraries. Change one or the other to match. In C, it's under Code Generation, in Fortran, Libraries.

I am puzzled by the link error for _Initialize unless you have also set /names:as_is. If so, please remove it. Then replace this code:

[plain]INTERFACE

!same error whether or not I use this interface
SUBROUTINE Initialize()
!DEC$ ATTRIBUTES :: Initialize
END SUBROUTINE Initialize

END INTERFACE[/plain]

with this:

[cpp]INTERFACE

SUBROUTINE Initialize() BIND(C,NAME="Initialize")
END SUBROUTINE Initialize

END INTERFACE[/cpp]

See where that gets you.

Folllowing your instructions, I am down to ONE unresolved symbol and again
following your lead I used dumpbin -symbols to track down which lib defines the
symbol. I found lib with the symbol and included it, but it still doesnt resolve.
I understand that when there is a symbol conflict you can get the same error. This
symbol IS in 4 libs so I made sure to include Only one of them.
The symbol is:

error LNK2019: unresolved external symbol __imp__GetOpenFileNameA@4 referenced in function _FileDialog

It is included in FlexLM libs: lmgr.lib, lmgr_md.lib lmgr_md_trl.liband lmgr_trl.lib. The calling function "_FileDialog"
is also in those same 3 libs. I only include lmgr_md.lib. I chose this one over the other 3
because it produces fewer errors, actually only one error.

This is what I see listed in the symbol table for all of the libs. Does the UNDEF mean its not defined anywhere?

040 00000000 UNDEF notype External | __imp__GetOpenFileNameA@4

At this point is seems its really no longer a Fortran issue, or never was except for the
way I used it, but I appreciate your help.

[Steven_L_Intel1 · Accepted solution]

That's another Win32 API routine. Add comdlg32.lib to the list of "Additional Dependencies".

[tsmithapp-geo-resear]

Quoting - Steve Lionel (Intel)

That's another Win32 API routine. Add comdlg32.lib to the list of "Additional Dependencies".

You sir, are "The Man". I now have a FlexLM enabled Fortan app! Thank you.

[Steven_L_Intel1]

My pleasure. Glad to hear that I'm not the only one in the world to have put these two together!