Trouble linking libimf.a on Linux

[janez-makovsek]

Dear All,

When building a custom IPP and MKL library on Linux, using the provided makefile from the Tools folder, we get an error about RELINK required with libm.so for various math functions.

We tried to link libimf both statically and dynamically, but because the parent application is also using libm.so, I guess, this triggers a RELINK warning (segmentation fault) when launching the application with the message that "cos" symbol needs to be from libm.

Is there some way how a shared library can statically link libifm.a  and at the same time the parent app can also use libm.so?

This issue also only surfaced with oneAPI 2021.4 and was not present before with 2021.2.

The temporary workaround is not to use libifm, but to link with libm. This of course defeats the purpose of using oneAPI in the first place. We cant change the dependency of the parent ap on the libm, because it is used by another shared library that the app depends upon.

The trouble is only, there appears to be no way to make use of libimf.

Thanks!
Atmapuri

[ShanmukhS_Intel]

Hi,

Thanks for posting in Intel Community. 

>>Is there some way how a shared library can statically link libifm.a  and at the same time the parent app can also use libm.so?

We have tried custom linking a library using the makefile under the same /tools/builder/  with a sample source code by giving the appropriate environment information  (We included cos function with custom library). We have used Link line advisor(link provided below)  and checked the ldd output to check the linking. We could see that libm.so got linked automatically. Attached the ldd output for your reference.

https://www.intel.com/content/www/us/en/developer/tools/oneapi/onemkl-link-line-advisor.html

We have performed this linking on linux machine with latest MKL 2021.4 version.

Could you please share us the ldd executable log output before relinking and a sample reproducer with custom build steps followed in linking, so that we could investigate your issue.

Best Regards,

Shanmukh.SS

[janez-makovsek]

Dear Shanmukh,

If you take this:

V:\opt\intel\oneapi\mkl\2021.4.0\tools\builder\makefile

as the starting point and download AMOS.F from www.netlib.org

and specify additionally in the makefile:

IFORT_LIB = "$(ifort_libpath)/libifcoremt.a" "$(ifort_libpath)/libimf.a" "$(ifort_libpath)/libsvml.a" "$(ifort_libpath)/libirc.a"
LIBAMOS_LIB = "/home/youruser/Lib/AMOS.a"

then add:

$(IFORT_LIB) \

$(LIBAMOS_LIB) \

to the "makefile" where all the libs are specified for the linker and use:

DF=ifort
DFLAGS=-c -qopenmp -O3 -axCORE-AVX512,CORE-AVX2,AVX -m64 -fpic
LINK=ar
LFLAGS=-rcs

in the separate makefile to make AMOS.a

of course you have to put a few of the functions from AMOS.F in to export (def) file: cairy, cbiry, ...

Here is the analysis of what happens with the resulting .so:

a.) If you build as-is, when you try to start the application, which is linked to the resulting mylapack.so file, this gives an error:

Relink `/usr/lib64/mylapack.so' with `/lib/x86_64-linux-gnu/libm.so.6' for IFUNC symbol `cos'

if the calling app isalso linked to libm.so

Here I have to say I don't understand how much the linker is trying to infer what the problem is, when giving this error message, in compare to what is actually the problem.

b.) If you analyze the ldd, there is no reference to libm, but also no reported unresolved external references. This is the ldd output from the resulting mylapack.so:

linux-vdso.so.1 (0x00007ffd07db5000)
libiomp5.so => /opt/intel/oneapi/compiler/2021.4.0/linux/compiler/lib/intel64_lin/libiomp5.so (0x00007f68461a1000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f684616f000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6846167000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6845f75000)
/lib64/ld-linux-x86-64.so.2 (0x00007f68519df000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f6845f6a000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6845f4f000)

Alternatively:

b.) I removed libimf.a from the IFORT_LIB, to somehow "force" the linking to libm, and in this case there are of course immediately linker errors returned by the "makefile":

/usr/bin/ld: /home/myuser/Lib/AMOS.a(amos.o): in function `cbesi_.V':
amos.f:(.text+0x357): undefined reference to `__libm_sse2_sincos'

If I remove AMOS.a from the makefile, then linker is happy to finish without reference to libimf.a.

However:

Getting a similar error when linking IPP. In that case, however it is sufficient, to add -lm to the linker command line. In the upper example, the -lm is also in the "makefile", but the resulting .so does not show that it was linked in at all.

Thanks!

Atmapuri

[janez-makovsek]

Dear Shanmukh

This is the output of ldd

after you append -limf to :

SYSTEM_LIBS = -lm -ldl -limf

in the makefile from here:

V:\opt\intel\oneapi\mkl\2021.4.0\tools\builder\makefile

As you can see, libm is absent.... and hence the error when linking the resulting .so with the calling app fails.

Kind Regards!
Atmapuri

[janez-makovsek · Accepted solution]

It appears I found the solution:

libm was left out from linking, if the libimf.a was specified within the linker group:

-Wl,--start-group \

..

-Wl,--end-group \

of the makefiles link command. What I wanted to achieve is static linking of libimf.a and shared link of libm. This was done by adding:

-l:libimf.a \

to the linker line outside of the group. This:

-limf

actually worked as well, but it resulted in dynamic link of the shared library.

Thanks!
Atmapuri

[ShanmukhS_Intel]

Hi,

Glad to know that your issue is resolved. If you need any additional information, please post a new question as this thread will no longer be monitored by Intel.

Best Regards,

Shanmukh.SS