Intel® oneAPI Math Kernel Library
Ask questions and share information with other developers who use Intel® Math Kernel Library.
Announcements
The Intel sign-in experience is changing in February to support enhanced security controls. If you sign in, click here for more information.
6680 Discussions

OneAPI MKL static link fails using ifort

Multipath
Novice
1,399 Views

I initially posted this question to the Intel FORTRAN Compiler forum but it probably belongs here.

 

We are having problems using the FORTRAN compiler to perform a static link of MKL. Here is what works and fails:

WORKS:

1. Using ld to create a shared object version of our library and including:

/Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_intel_lp64.a
/Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_sequential.a
/Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_core.a

2. Using ifort to create a program and including the

-qmkl=sequential

flag.

However this ignores the specified .a versions and uses the .so versions.

FAILS:

Using ifort to create a program and using the recommendations of the Link Line Advisor

-Wl,--start-group
/Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_intel_lp64.a
/Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_sequential.a
/Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_core.a
-Wl,--end-group

This produces pages of errors of the form:

/Intel/Linux/oneapi/compiler/2022.0.2/linux/bin/intel64/ifort ld: fmslib.a(rsdaf.o): in function `rsdaf_.h': rsdaf.f:(.text+0x21c7): undefined reference to `dscal_' ld: rsdaf.f:(.text+0x2282): undefined reference to `daxpy_' ld: fmslib.a(rsdaf.o): in function `rsdaf_.A':
rsdaf.f:(.text+0x5ea8): undefined reference to `dscal_'
ld: rsdaf.f:(.text+0x5f5f): undefined reference to `daxpy_' ld: fmslib.a(rndaf.o): in function `rndaf_.h':
rndaf.f:(.text+0x2249): undefined reference to `dscal_' ld: rndaf.f:(.text+0x2304): undefined reference to `daxpy_'
ld: fmslib.a(rndaf.o): in function `rndaf_.A':
rndaf.f:(.text+0x602d): undefined reference to `dscal_'
ld: rndaf.f:(.text+0x60e4): undefined reference to `daxpy_' ld: fmslib.a(chdaf.o): in function `chdaf_.h': chdaf.f:(.text+0x21e8): undefined reference to `dscal_' ld: chdaf.f:(.text+0x22fc): undefined reference to `daxpy_'
ld: fmslib.a(chdaf.o): in function `chdaf_.A':
chdaf.f:(.text+0x5c81): undefined reference to `dscal_'
ld: chdaf.f:(.text+0x5d93): undefined reference to `daxpy_'

...

 

The link line that fails isifort -auto -threads -reentrancy threaded -fpic -ftz -nofor-main -ldl -o MatrixWarrior_dbg MatrixWarrior.o mw.a fmsnoshr.a fmslib.a fmsint.a fmslib.a fmsint.a yesgpu.a fmslib.a fmsint.a fmslib.a fmsint.a yesgpu.a -Wl,--start-group /Nvidia/Linux/cuda-11.4/lib64/libculibos.a /Nvidia/Linux/cuda-11.4/lib64/libcublas_static.a /Nvidia/Linux/cuda-11.4/lib64/libcublasLt_static.a /Nvidia/Linux/cuda-11.4/lib64/libculibos.a /Nvidia/Linux/cuda-11.4/lib64/libcudart_static.a -lrt -Wl,--end-group /Intel/Linux/oneapi/compiler/2022.0.2/linux/compiler/lib/intel64_lin/libimf.a /Intel/Linux/oneapi/compiler/2022.0.2/linux/compiler/lib/intel64_lin/libirc.a /Intel/Linux/oneapi/compiler/2022.0.2/linux/compiler/lib/intel64_lin/libifport.a /Intel/Linux/oneapi/compiler/2022.0.2/linux/compiler/lib/intel64_lin/libsvml.a /Intel/Linux/oneapi/compiler/2022.0.2/linux/compiler/lib/intel64_lin/libirng.a /lib/x86_64-linux-gnu/libc-2.31.so /usr/lib/x86_64-linux-gnu/libc_nonshared.a /lib/x86_64-linux-gnu/libstdc++.so.6 -L /lib/x86_64-linux-gnu -L /usr/lib/gcc/x86_64-linux-gnu/9 -Wl,--start-group /Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_intel_lp64.a /Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_sequential.a /Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_core.a -Wl,--end-group -Wl,--start-group /Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_intel_lp64.a /Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_sequential.a /Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_core.a -Wl,--end-group -lpthread -ldl -lm

If I simply add

-qmkl=sequential

to the link line it works

 

ls -al MatrixWarrior_dbg -rwxrwxr-x 1 ron ron 134192944 Mar 14 07:19 MatrixWarrior_dbg


ldd MatrixWarrior_dbg
linux-vdso.so.1 (0x00007fffeedfa000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f8326566000)
libmkl_intel_lp64.so.2 => /Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_intel_lp64.so.2 (0x00007f83256c6000) libmkl_sequential.so.2 => /Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_sequential.so.2 (0x00007f8323cac000)
libmkl_core.so.2 => /Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_core.so.2 (0x00007f831f8f5000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f831f8eb000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f831f6f9000) libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f831f517000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f831f4f4000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f831f3a5000) /lib64/ld-linux-x86-64.so.2 (0x00007f8326588000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f831f388000)

 

but it uses the shared object version of MKL.

 

Any suggestions?

 

 

0 Kudos
20 Replies
Khang_N_Intel
Employee
1,378 Views

Hi,

Can you provide us with a test code so that we can reproduce the error?

Thanks,

Khang

Multipath
Novice
1,346 Views

I was hoping you could offer suggestions that we might try since it worked with previous versions of the Intel software, works when linking a shared object, and works with the shared libraries.

 

I can write a reproducer but that would take a couple days.

 

Is there a place I can upload my .a files?  Would that be helpful?

 

Ron

Multipath
Novice
1,207 Views

I have created an archive which contains all the files you will need to perform this link:  It does not contain the Intel compiler libraries or MKL, which I assume you have (or may want to change).  Where can I upload it (302 MB)?

 

302767113 Mar 14 17:36 testlink.tar.gz

 

It contains the following script listed below:

F:/FMS/ver80/Linux/CUDA114/testlink >cat testlink.ksh
#
# Choose one of the following:
mklSequential="" #Fails
mklSequential="-qmkl=sequential" #Works but produces a shared mkl version

#Compiler
echo "FORTRAN Compiler Used:"
which ifort
echo ""
COMMAND="ifort "
COMMAND="$COMMAND -auto -threads -reentrancy threaded "
COMMAND="$COMMAND -fpic -ftz -nofor-main -ldl "
COMMAND="$COMMAND $mklSequential "
#COMMAND="$COMMAND -Wl,-verbose "
#COMMAND="$COMMAND -Wl,--verbose "
#
#FMSlib Software
COMMAND="$COMMAND -o MatrixWarrior_dbg MatrixWarrior.o"
COMMAND="$COMMAND mw.a "
COMMAND="$COMMAND fmsnoshr.a fmslib.a fmsint.a fmslib.a fmsint.a yesgpu.a "
#
#Nvidia Software
COMMAND="$COMMAND -Wl,--start-group "
COMMAND="$COMMAND libculibos.a"
COMMAND="$COMMAND libcublas_static.a "
COMMAND="$COMMAND libcublasLt_static.a"
COMMAND="$COMMAND libculibos.a"
COMMAND="$COMMAND libcudart_static.a "
COMMAND="$COMMAND -lrt "
COMMAND="$COMMAND -Wl,--end-group "
#
#Intel Compiler Software
#Will need to edit this for your machine
dirIntel="/Intel/Linux/oneapi/compiler/2022.0.2/linux/compiler/lib/intel64_lin"
COMMAND="$COMMAND $dirIntel/libimf.a"
COMMAND="$COMMAND $dirIntel/libirc.a "
COMMAND="$COMMAND $dirIntel/libifport.a "
COMMAND="$COMMAND $dirIntel/libirng.a "
#
#Intel MKL Softward
#Will need to edit this for your machine
dirmkl="/Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64"
COMMAND="$COMMAND -Wl,--start-group "
COMMAND="$COMMAND $dirmkl/libmkl_intel_lp64.a "
COMMAND="$COMMAND $dirmkl/libmkl_sequential.a "
COMMAND="$COMMAND $dirmkl/libmkl_core.a "
COMMAND="$COMMAND -Wl,--end-group "
#
#Linux Software
COMMAND="$COMMAND /lib/x86_64-linux-gnu/libc-2.31.so "
COMMAND="$COMMAND /usr/lib/x86_64-linux-gnu/libc_nonshared.a "
COMMAND="$COMMAND /lib/x86_64-linux-gnu/libstdc++.so.6 "
COMMAND="$COMMAND -L /lib/x86_64-linux-gnu "
COMMAND="$COMMAND -L /usr/lib/gcc/x86_64-linux-gnu/9 "
COMMAND="$COMMAND -lpthread -ldl -lm "
echo ""
echo "$COMMAND"
echo ""
$COMMAND
echo ""
COMMAND="ls -al MatrixWarrior_dbg"
echo "$COMMAND"
echo ""
$COMMAND
COMMAND="ldd MatrixWarrior_dbg"
echo "$COMMAND"
echo ""
$COMMAND

Khang_N_Intel
Employee
1,174 Views

HI,


There is an option to attach the file when you create a forum message.


However, yours is 302MB which is much larger than the maximum allowed size of 77MB.


My suggestion is to create a priority support ticket so that you can securely send the file to us.


Best regards,

Khang


Multipath
Novice
1,142 Views

Hi Khang -

 

I created a version with the Nvidia software stubbed out which shows the same MKL link problem.  It is smaller (2MB) so should upload.  Naturally when built it will not run.

 

 

Khang_N_Intel
Employee
1,139 Views

Thank you, I will take a look and will let you know should I need more info.

'

Best,

Khang


Khang_N_Intel
Employee
1,067 Views

Hi,


I modified the script file to match with the folders on my system for the compiler, mkl folder. I also changed the folder of the file libstdc++.so.6 to get the code to compile and link.


I was able to compile and link with no error.


Let me try it on another system to make sure.


Khang


Multipath
Novice
1,054 Views

Hi -

That is good news.

I have attached another file which will actually run if it builds.  It is small (does not include the Nvidia software).

On my system this fails to link, although it says it can find the MKL files. (./testlink.ksh | grep mkl)

If I copy the 3 MKL files to the local directory (and change their path), it works.

I have tried all the options including -L, -l, -Wl,--sttart-group ... -Wl,--end-group and nothing seems to fix it.

Is there an environment variable that needs to be set for ld to open the files during the link?

Thanks, Ron

Khang_N_Intel
Employee
1,041 Views

Hi Ron,


I did try the new code and I didn't see any issue relating to linking to oneMKL.


Best,

Khang


Multipath
Novice
1,018 Views

First, a slight correction to the script.  libFMS should be

libFMS="mw.a fmsnoshr.a fmslib.a fmsint.a nogpu.a fmslib.a fmsint.a "

instead of

libFMS="mw.a fmsnoshr.a fmslib.a fmsint.a nogpu.a "

do to circular references and a static link.

 

I think the problem may be related to installing the software in a directory that is different than the default (which is different from my  case and your test),  I installed it at

/Intel/Linux/oneapi

with the MKL files of interest

-rw-r--r-- 1 ron ron 34415724 Nov 12 05:40 /Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_intel_lp64.a
-rw-r--r-- 1 ron ron 38539080 Nov 12 05:40 /Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_sequential.a
-rw-r--r-- 1 ron ron 577561212 Nov 12 05:40 /Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_core.a

I cannot understand why these files are not searched by ld during the link.

When I run

IntelDir="/Intel/Linux/oneapi"
env > env1.txt
COMMAND="source $IntelDir/setvars.sh"
echo $COMMAND
$COMMAND
env > env2.txt
diff env2.txt env1.txt

to look at the environment variables that are set by setvar.sh, they correctly show /Intel/Linux/oneapi as the root directory.  The ones containing MKL are

< PKG_CONFIG_PATH=/Intel/Linux/oneapi/vtune/2022.0.0/include/pkgconfig/lib64:/Intel/Linux/oneapi/vpl/2022.0.0/lib/pkgconfig:/Intel/Linux/oneapi/tbb/2021.5.1/env/../lib/pkgconfig:/Intel/Linux/oneapi/mpi/2021.5.1/lib/pkgconfig:/Intel/Linux/oneapi/mkl/2022.0.2/lib/pkgconfig:/Intel/Linux/oneapi/ippcp/2021.5.1/lib/pkgconfig:/Intel/Linux/oneapi/inspector/2022.0.0/include/pkgconfig/lib64:/Intel/Linux/oneapi/dpl/2021.6.0/lib/pkgconfig:/Intel/Linux/oneapi/dnnl/2022.0.2/cpu_dpcpp_gpu_dpcpp/../lib/pkgconfig:/Intel/Linux/oneapi/dal/2021.5.3/lib/pkgconfig:/Intel/Linux/oneapi/compiler/2022.0.2/lib/pkgconfig:/Intel/Linux/oneapi/ccl/2021.5.1/lib/pkgconfig:/Intel/Linux/oneapi/advisor/2022.0.0/include/pkgconfig/lib64:
< LIBRARY_PATH=/Intel/Linux/oneapi/vpl/2022.0.0/lib:/Intel/Linux/oneapi/tbb/2021.5.1/env/../lib/intel64/gcc4.8:/Intel/Linux/oneapi/mpi/2021.5.1//libfabric/lib:/Intel/Linux/oneapi/mpi/2021.5.1//lib/release:/Intel/Linux/oneapi/mpi/2021.5.1//lib:/Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64:/Intel/Linux/oneapi/ipp/2021.5.2/lib/intel64:/Intel/Linux/oneapi/ippcp/2021.5.1/lib/intel64:/Intel/Linux/oneapi/ipp/2021.5.2/lib/intel64:/Intel/Linux/oneapi/dnnl/2022.0.2/cpu_dpcpp_gpu_dpcpp/lib:/Intel/Linux/oneapi/dal/2021.5.3/lib/intel64:/Intel/Linux/oneapi/compiler/2022.0.2/linux/compiler/lib/intel64_lin:/Intel/Linux/oneapi/compiler/2022.0.2/linux/lib:/Intel/Linux/oneapi/clck/2021.5.0/lib/intel64:/Intel/Linux/oneapi/ccl/2021.5.1/lib/cpu_gpu_dpcpp
< LD_LIBRARY_PATH=/Intel/Linux/oneapi/vpl/2022.0.0/lib:/Intel/Linux/oneapi/tbb/2021.5.1/env/../lib/intel64/gcc4.8:/Intel/Linux/oneapi/mpi/2021.5.1//libfabric/lib:/Intel/Linux/oneapi/mpi/2021.5.1//lib/release:/Intel/Linux/oneapi/mpi/2021.5.1//lib:/Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64:/Intel/Linux/oneapi/itac/2021.5.0/slib:/Intel/Linux/oneapi/ipp/2021.5.2/lib/intel64:/Intel/Linux/oneapi/ippcp/2021.5.1/lib/intel64:/Intel/Linux/oneapi/ipp/2021.5.2/lib/intel64:/Intel/Linux/oneapi/dnnl/2022.0.2/cpu_dpcpp_gpu_dpcpp/lib:/Intel/Linux/oneapi/debugger/2021.5.0/gdb/intel64/lib:/Intel/Linux/oneapi/debugger/2021.5.0/libipt/intel64/lib:/Intel/Linux/oneapi/debugger/2021.5.0/dep/lib:/Intel/Linux/oneapi/dal/2021.5.3/lib/intel64:/Intel/Linux/oneapi/compiler/2022.0.2/linux/lib:/Intel/Linux/oneapi/compiler/2022.0.2/linux/lib/x64:/Intel/Linux/oneapi/compiler/2022.0.2/linux/lib/oclfpga/host/linux64/lib:/Intel/Linux/oneapi/compiler/2022.0.2/linux/compiler/lib/intel64_lin:/Intel/Linux/oneapi/ccl/2021.5.1/lib/cpu_gpu_dpcpp
< MKLROOT=/Intel/Linux/oneapi/mkl/2022.0.2
< NLSPATH=/Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/locale/%l_%t/%N:/Intel/Linux/oneapi/compiler/2022.0.2/linux/compiler/lib/intel64_lin/locale/%l_%t/%N
< PATH=/Intel/Linux/oneapi/vtune/2022.0.0/bin64:/Intel/Linux/oneapi/vpl/2022.0.0/bin:/Intel/Linux/oneapi/mpi/2021.5.1//libfabric/bin:/Intel/Linux/oneapi/mpi/2021.5.1//bin:/Intel/Linux/oneapi/mkl/2022.0.2/bin/intel64:/Intel/Linux/oneapi/itac/2021.5.0/bin:/opt/intel/oneapi/intelpython/latest/bin:/opt/intel/oneapi/intelpython/latest/condabin:/Intel/Linux/oneapi/inspector/2022.0.0/bin64:/Intel/Linux/oneapi/dpcpp-ct/2022.0.0/bin:/Intel/Linux/oneapi/dev-utilities/2021.5.2/bin:/Intel/Linux/oneapi/debugger/2021.5.0/gdb/intel64/bin:/Intel/Linux/oneapi/compiler/2022.0.2/linux/lib/oclfpga/bin:/Intel/Linux/oneapi/compiler/2022.0.2/linux/bin/intel64:/Intel/Linux/oneapi/compiler/2022.0.2/linux/bin:/Intel/Linux/oneapi/clck/2021.5.0/bin/intel64:/Intel/Linux/oneapi/advisor/2022.0.0/bin64:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
< CPATH=/Intel/Linux/oneapi/vpl/2022.0.0/include:/Intel/Linux/oneapi/tbb/2021.5.1/env/../include:/Intel/Linux/oneapi/mpi/2021.5.1//include:/Intel/Linux/oneapi/mkl/2022.0.2/include:/Intel/Linux/oneapi/ipp/2021.5.2/include:/Intel/Linux/oneapi/ippcp/2021.5.1/include:/Intel/Linux/oneapi/ipp/2021.5.2/include:/Intel/Linux/oneapi/dpl/2021.6.0/linux/include:/Intel/Linux/oneapi/dpcpp-ct/2022.0.0/include:/Intel/Linux/oneapi/dnnl/2022.0.2/cpu_dpcpp_gpu_dpcpp/lib:/Intel/Linux/oneapi/dev-utilities/2021.5.2/include:/Intel/Linux/oneapi/dal/2021.5.3/include:/Intel/Linux/oneapi/ccl/2021.5.1/include/cpu_gpu_dpcpp

So  LIBRARY_PATH, LD_LIBRARY_PATH and PATH all include the correct directory to search.

During the first output of the link the following messages occur:

attempt to open /Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_intel_lp64.a succeeded /Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_intel_lp64.a

attempt to open /Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_sequential.a succeeded /Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_sequential.a

attempt to open /Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_core.a succeeded
/Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_core.a

which would indicate that ld can find the files.

 

However later in the link, all references to entry points in these files are undefined.

I have tried several options to pass the files through ifort, including the one in the script,

COMMAND="$COMMAND -Wl,--start-group "
COMMAND="$COMMAND $dirMKL/libmkl_intel_lp64.a "
COMMAND="$COMMAND $dirMKL/libmkl_sequential.a "
COMMAND="$COMMAND $dirMKL/libmkl_core.a "
COMMAND="$COMMAND -Wl,--end-group "

but nothing seems to work.

The one option that does work is to move the 3 files to the local directory and search for them there.

So I am at a loss why ld does not look in these files?

does ifort assume they are installed in the default directory?

Is there some other environment variable that can be set?

Thanks, Ron

 

 

 

Multipath
Novice
937 Views

Hi Khang -

I ran some more tests and found the following:

 

MKLROOT is correctly defined as

 /Intel/Linux/oneapi/mkl/2022.0.2

in setvar.sh

However the directory containing the files

$MKLROOT/lib/intel64

is not defined in PATH.

If I define the directory in PATH or include

-L$MKLROOT/lib/intel64

it helps.

If I include the following on the ifort line

-lmkl_intel_lp64

-lmkl_sequential

-lmkl_core

it looks for the .so version of these files and fails.

If I remove the .so version of these files it works.

When I specify the full path name of these files to ifort, it finds them during the first phase but does not search them later to get the definition of the unsatisfied externals, even with the directory defined in PATH or -L.  It does find them if the files are in the local directory.

If I use ld directly and specify the full path name with the files in $MKLROOT/lib/intel64 directory, it works.

How can I get ifort to search these files during the second phase of linking without changing the distribution?

Ron

 

Ron

 

Khang_N_Intel
Employee
859 Views

Hi Ron,


Can you provide the following information?

 

  1. Full ifort command with full output (error and not error).
  2. Method used to install oneMKL (apt, yum, oneapi installer etc. Toolkit or standalone, python or regular)
  3. Output of command: $ls -lah /Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64


Thanks,

Khang


Multipath
Novice
841 Views

Hi Khang -

We download the offline version of the BaseKit and HPCKit

We added the mkl directory to PATH.

Attached are files containing the 3 cases:

Case 1:

This case uses the full path names of the MKL libraries.  They are found during the first part of the link but not when looking for external definitions. (This one seems strange to me).

Script: testlink2.ksh

Output: testlink2.out

Case 2:

This script uses MKL names without the lib or .a extensions.  It works but uses the .so version of the files.

Script: testlink.ksh

Output: testlinkSO.out

Directory: mkldir_shared.txt

Case 3:

The .so version of the MKL files were moved to a subdirectory.  This script is the same as Case 2 but this time it finds the .a version of the files.

Script: Same as Case 2:

Output: testlinkA.out

Directory: mkldir_noshared.txt

Subdirectory: shared.txt

Khang_N_Intel
Employee
825 Views

Thanks Ron!


Khang_N_Intel
Employee
808 Views

Hi Ron,


I am escalating the issue to the mkl developer so that they can take a closer look since there is no obvious issue with static linking oneMKL to your code.


I will let you know if we discover something about this issue.


Best regards,

Khang


Multipath
Novice
770 Views

Hi Khang -

The Fortran compiler group might also want to take a look at this.  For Case 1, where the paths to the MKL files are explicitly specified, should work.  There is no reason that it finds them during the first part of the link and then cannot search them during the second part.

For Cases 2 and 3 the .so and .a files either need to be stored in different directories or the compiler/linker need to have an option to select between .so and .a

Thanks, Ron

Khang_N_Intel
Employee
763 Views

Hi Ron,


Thank you for the note.


Khang


Khang_N_Intel
Employee
588 Views

Hi Ron,


We checked it again and were not able to reproduce the error.


These are the comments:


  • On Linux, dynamic linking is the default of -qmkl (see here). So linking with dynamic libraries is expected when the customer specified -qmkl=sequential.
  • Based on the customer's description:

Using ld to create a shared object version of our library and including:

/Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_intel_lp64.a

/Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_sequential.a

/Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_core.a

it's not clear to me what the customer did exactly and if this has an effect on linking.

  • In testlink2.out provided by the customer:

ld: mode elf_x86_64

attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/Scrt1.o succeeded

/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/Scrt1.o

attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/crti.o succeeded

/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/crti.o

attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/crtbeginS.o succeeded

/usr/lib/gcc/x86_64-linux-gnu/9/crtbeginS.o

attempt to open /Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_intel_lp64.a succeeded

/Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_intel_lp64.a

attempt to open /Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_sequential.a succeeded

/Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_sequential.a

attempt to open /Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_core.a succeeded

/Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_core.a

attempt to open /Intel/Linux/oneapi/compiler/2022.0.2/linux/compiler/lib/intel64_lin/libimf.a succeeded

/Intel/Linux/oneapi/compiler/2022.0.2/linux/compiler/lib/intel64_lin/libimf.a

attempt to open /Intel/Linux/oneapi/compiler/2022.0.2/linux/compiler/lib/intel64_lin/libirc.a succeeded

/Intel/Linux/oneapi/compiler/2022.0.2/linux/compiler/lib/intel64_lin/libirc.a

attempt to open /Intel/Linux/oneapi/compiler/2022.0.2/linux/compiler/lib/intel64_lin/libifport.a succeeded

/Intel/Linux/oneapi/compiler/2022.0.2/linux/compiler/lib/intel64_lin/libifport.a

attempt to open /Intel/Linux/oneapi/compiler/2022.0.2/linux/compiler/lib/intel64_lin/libsvml.a succeeded

/Intel/Linux/oneapi/compiler/2022.0.2/linux/compiler/lib/intel64_lin/libsvml.a

attempt to open /Intel/Linux/oneapi/compiler/2022.0.2/linux/compiler/lib/intel64_lin/libdl.so failed

attempt to open /Intel/Linux/oneapi/compiler/2022.0.2/linux/compiler/lib/intel64_lin/libdl.a failed

attempt to open /lib/x86_64-linux-gnu/libdl.so succeeded

/lib/x86_64-linux-gnu/libdl.so

attempt to open MatrixWarrior.o succeeded

MatrixWarrior.o

it looks strange to me that it searches mkl libraries (and oneapi compiler libraries) right at the beginning when the linker doesn't know what symbols need to be resolved. This is the output I got:

ld: mode elf_x86_64

attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/Scrt1.o succeeded

/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/Scrt1.o

attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/crti.o succeeded

/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/crti.o

attempt to open /usr/lib/gcc/x86_64-linux-gnu/9/crtbeginS.o

succeeded/usr/lib/gcc/x86_64-linux-gnu/9/crtbeginS.o

attempt to open /lib/x86_64-linux-gnu/libdl.so succeeded

/lib/x86_64-linux-gnu/libdl.so

attempt to open MatrixWarrior.o succeeded

MatrixWarrior.o

Maybe double-check with the customer if the files used to generate testlink2.out are the same as the ones attached.

  • In the customer's link line,

ifort -auto -threads -reentrancy threaded -fpic -ftz -nofor-main -ldl -o MatrixWarrior_dbg MatrixWarrior.o mw.a fmsnoshr.a fmslib.a fmsint.a fmslib.a fmsint.a yesgpu.a fmslib.a fmsint.a fmslib.a fmsint.a yesgpu.a -Wl,--start-group /Nvidia/Linux/cuda-11.4/lib64/libculibos.a /Nvidia/Linux/cuda-11.4/lib64/libcublas_static.a /Nvidia/Linux/cuda-11.4/lib64/libcublasLt_static.a /Nvidia/Linux/cuda-11.4/lib64/libculibos.a /Nvidia/Linux/cuda-11.4/lib64/libcudart_static.a -lrt -Wl,--end-group /Intel/Linux/oneapi/compiler/2022.0.2/linux/compiler/lib/intel64_lin/libimf.a /Intel/Linux/oneapi/compiler/2022.0.2/linux/compiler/lib/intel64_lin/libirc.a /Intel/Linux/oneapi/compiler/2022.0.2/linux/compiler/lib/intel64_lin/libifport.a /Intel/Linux/oneapi/compiler/2022.0.2/linux/compiler/lib/intel64_lin/libsvml.a /Intel/Linux/oneapi/compiler/2022.0.2/linux/compiler/lib/intel64_lin/libirng.a /lib/x86_64-linux-gnu/libc-2.31.so /usr/lib/x86_64-linux-gnu/libc_nonshared.a /lib/x86_64-linux-gnu/libstdc++.so.6 -L /lib/x86_64-linux-gnu -L /usr/lib/gcc/x86_64-linux-gnu/9 -Wl,--start-group /Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_intel_lp64.a /Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_sequential.a /Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_core.a -Wl,--end-group -Wl,--start-group /Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_intel_lp64.a /Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_sequential.a /Intel/Linux/oneapi/mkl/2022.0.2/lib/intel64/libmkl_core.a -Wl,--end-group -lpthread -ldl -lm

there are multiple instances of Wl,--start-group and end-group (and duplicated mkl libraries). Maybe check with the customer if this is the intended usage.


Best regards,

Khang


Khang_N_Intel
Employee
429 Views

Hi Ron,


Any news on this?

We haven't heard from you since we last posted a message back in Apr 20th.

Since there is no news we are going to close this issue.


Best regards,

Khang



Khang_N_Intel
Employee
422 Views

This thread is closed!

This thread will be no longer monitored!


Reply