Fortran compiler is ignoring my settings for export symbols

[CJBattles]

I am trying to build LAPACK and BLAS with Intel Fortran to replace a current implementation using minGW that seems to be causing distribution runtime issues.

I am using CMAKE to create the project / solution files that came with LAPACK.  However, it doesn't seem to matter what compiler options I use to set the export symbols, I can only get them exported as all-caps.  (Although the function names are all-caps, so maybe it is really being interpreted "as-is".)  I have tried all combinations of the calling convention and setting /names:lowercase and /assume:underscore, but I always get all-caps.

I read in various forums (from Steve Lionel) that some compiler options over-ride these flags.  But I'm not sure that I know what CMAKE might be setting or another compiler flag to over-ride it.

Unfortunately the application using the (old) LAPACK / BLAS DLLs seems to be expecting lowercase with an appended underscore.  I think this might come from the fact that the project originally came from Linux, but I'm not familiar with Linux conventions.  I'm not sure if or how to change that to look for all-caps, because it seems to be done somewhere in the CMake magic.

I would appreciate any ideas.  Thanks.

[FortranFan]

@CJBattles ,

Re: "I would appreciate any ideas" - you may want to consider BIND(C, name="..") clause that is part of standard Fortran and see if it that will be applicable to your need(s):  

[FortranFan]

Depending on what exactly is needed, ATTRIBUTES ALIAS may be of help.

[CJBattles]

Thanks - That would be my ideal approach, but that would mean that I would be modifying the code for a "standardized" library.  It also appears that they are trying to adhere to F77 standards (yeah, I know...) but this approach would require the 2003 standard.

[Steve_Lionel]

First of all, there are no compiler settings for symbol exports. Exports are done using an ATTRIBUTES DLLEXPORT directive in each procedure to export. You're really talking about changing the convention for global symbol names.

Can you provide a small test case?  Yes, the trailing underscore is a Linux convention.

[CJBattles]

Thanks, Steve.  I'm not sure what kind of example would be helpful...  

LAPACK / BLAS, for example, has a subroutine,  DGEMV.  The exported name by the compiler is "DGEMV".  (Which makes perfect sense to me, but...) The DLLs that were made by the minGW compiler exported this name as "dgemv_".  And this is what the calling program is looking for.  

There are 2 flags under the  compiler settings (not linker): /names:lowercase and /assume:underscore which look like they would give me what I need.  I saw in another article / reply you wrote elsewhere that indicated that "STDCALL" vs "default" vs "C" could over-ride the setting of these values.  However, I have tried every combination I could think of, and the exported names for the subroutines are always in all-caps, "DGEMV".  

[Steve_Lionel]

Please construct a small test routine that shows the problem, and show us from a command line prompt how you invoke the compiler and how you determine that the names are uppercase. (Which they will be by default - as others have indicated you can change this in various ways.)

[CJBattles]

I guess I should also add that the symbols get exported by CMake's  "CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS".  I think I read that this tells the linker to create an export definition for every symbol in the .obj files.  

I know it's clumsy and not ideal, but the source library is a "cross-platform" standardized library, so I don't want to change their code.

[mecej4]

CJBattles:

Are you aware that Intel Parallel Studio includes Intel's MKL library? That library includes high performance BLAS and Lapack routines, and much more. If your code calls BLAS and Lapack routines with implicit interfaces, all that you have to do is to add the /Qmkl option when compiling and linking your source files.

[CJBattles]

Thanks.  I'll try it.

[mecej4]

It is best to avoid having to use a library compiled by one compiler (e.g., Mingw Gcc) from objects compiled by another compiler (Intel) or with different calling conventions.

BLAS and Lapack contain several thousands of routines, so writing BIND(C) and other interfaces is not feasible unless the number of routines of interest is small or you have an interface generator program.

A look at http://www.icl.utk.edu/~mgates3/docs/lapack.html should put to rest any doubts about this.

[CJBattles]

Agreed! And dangerous / unpredictable!  

I wasn't trying to combine object files - my intention was to put them behind a DLL...  Still a complicated coordination.