Linking against MKL with ifort "-assume nounderscore" fails to find symbols

[ereisch]

I'm newly-building a program against MKL (I previously used local implementations of BLAS routines, but now want to use the Intel optimized ones).  A brief snippet of my modified routine contains the following code:

  SUBROUTINE FOO
  USE :: BLAS95
  IMPLICIT NONE

  [...]

  REAL*4  KVEC(STOP-START+1,3), SPSI_CTHETA

  [...]
  CALL SCAL( KVEC(:, 2), SPSI_CTHETA )
  [...]
  END

When I build the subroutine with "-assume nounderscore -qmkl=sequential" in ifort, then link with "$(MKLROOT)/lib/intel64/libmkl_intel_lp64.a $(MKLROOT)/lib/intel64/libmkl_sequential.a $(MKLROOT)/lib/intel64/libmkl_core.a $(MKLROOT)/lib/intel64/libmkl_blas95_lp64.a", I receive undefined references to "sscal_f95".  I can fix this by passing a flag to the linker to alias "sscal_f95=sscal_f95_".

Is there a missing "!DEC ATTRIBUTES DEFAULT :: SSCAL_F95" (or something similar) in the MKL definition for the BLAS functions that would remove the effects of the "assume nounderscore" compiler argument during compilation?

[mecej4]

Do you realize that for the "-assume nounderscore" option to be applied consistently, you may need to recompile the source files from which BLAS95.mod was generated, before compiling your own Fortran source files that USE the module?

A different point, also to be checked: do the Linux MKL libraries support calling with and without underscore decoration?

[ereisch]

I was under the impression that the function decorations and attributes are all carried around in the *.mod file (this appears to be how the compiler's *.mod files work, such as ifestablish.mod, ieee_arithmetic.mod, etc.), so they are compatible with all compiler arguments without having to rebuild the module files with each compiler option change.

[mecej4 · Accepted solution]

What you said comes into force only when you (re)compile the source file .../Intel/oneAPI/mkl/latest/include/mkl_blas.f90 with the non-default compiler options that you chose. If you did not recompile mkl_blas.f90, the module file is that supplied with the MKL installer, and that .mod file does not correspond to "-assume nounderscore".

When you build using precompiled objects and libraries, using "-assume nounderscore" may result in linker errors (unsatisfied externals) unless the precompiled objects contain both versions (with and without underscore) of the exported symbols.

[AryanK_Intel]

Hi,

Gentle Reminder:

We haven't heard back from you. Could you please let us know whether the provided information is helpful?

Thanks and Regards,

Aryan.

[AryanK_Intel]

Hi,

Gentle Reminder:

We haven't heard back from you. Could you please let us know whether the provided information is helpful?

Thanks and Regards,

Aryan.