Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28510 Discussions

Fortran compiler is ignoring my settings for export symbols

CJBattles
Beginner
1,706 Views

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.

 

0 Kudos
11 Replies
FortranFan
Honored Contributor II
1,700 Views

@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):  

0 Kudos
FortranFan
Honored Contributor II
1,696 Views

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

0 Kudos
CJBattles
Beginner
1,694 Views

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.

0 Kudos
Steve_Lionel
Honored Contributor III
1,698 Views

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.

0 Kudos
CJBattles
Beginner
1,692 Views

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".  

 

0 Kudos
Steve_Lionel
Honored Contributor III
1,668 Views

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.)

0 Kudos
CJBattles
Beginner
1,689 Views

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.

 

0 Kudos
mecej4
Honored Contributor III
1,678 Views

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.

0 Kudos
CJBattles
Beginner
1,673 Views
0 Kudos
mecej4
Honored Contributor III
1,658 Views

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.

0 Kudos
CJBattles
Beginner
1,645 Views

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.

0 Kudos
Reply