Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.
7944 Discussions

imf gets linked dynamically using -static-intel

erling_andersen
New Contributor I
1,757 Views

The following is done with 

 

oneapi-2021.3.0.3219

 

Run

 

icx -o test -static-intel test.c -lm 

 

then do

 

ldd test

 

and you get

 

     libimf.so => /remote/public/linux/opt/intel/oneapi-2021.3.0.3219/compiler/2021.3.0/linux/compiler/lib/intel64_lin/libimf.so (0x00007fa52046b000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa5200cd000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa51fec9000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa51fad8000)
        libintlc.so.5 => /remote/public/linux/opt/intel/oneapi-2021.3.0.3219/compiler/2021.3.0/linux/compiler/lib/intel64_lin/libintlc.so.5 (0x00007fa51f860000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fa520af3000)

 

Why is imf linked dynamically?

0 Kudos
5 Replies
erling_andersen
New Contributor I
1,623 Views

Also libintlc is also linked dynamincally.

 

What is even more strange if if you remove -lm you get

 


        linux-vdso.so.1 (0x00007ffca51ec000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3791ffb000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3791df7000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3791a06000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f3792399000)

 

which is what I think is correct.

 

Very strange.

 

 

0 Kudos
ShanmukhS_Intel
Moderator
1,709 Views

Hi,

 

Thanks for reaching out to us.

 

We have tried compiling and running the shared c source file as per the steps shared.

We see that dynamic linking has happened in 2021.3 version. However, We have tried performing the same in latest oneAPI environment(v2021.4) and we see that libimf hasn't been dynamically linked over here.

We would like to recommend you to use the latest Intel oneAPI environment available.

 

Attached the screenshots for your reference.

 

Best regards,

Shanmukh.SS

 

0 Kudos
ShanmukhS_Intel
Moderator
1,601 Views

Hi,


Reminder:

Has the solution provided helped? Is your issue resolved? Please let us know if the issue still persists.


Best Regards,

Shanmukh.SS


0 Kudos
ShanmukhS_Intel
Moderator
1,510 Views

Hi,


We assume 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


0 Kudos
EAnde4
Beginner
884 Views

We see the same issue in oneapi-2022.2.0.262 (ompiler 2022.1.0 for linux). The command line that produces the shared library looks like this:

icpx -shared -o bld/ulfborg/final/default/lib/pybrid/3.10/unsigned/fragments.cpython-310-x86_64-linux-gnu.so -Wl,--version-script=/home/ulfw/mosekprj/dev/bld/ulfborg/final/default/fusion/pybrid/mosek-py3.def -ffreestanding -static-intel -v -shared bld/ulfborg/final/default/src/pybrid/3.10/mosek-py3.os -Wl,--start-group -lm -ldl -Wl,--end-group

The output (from verbose mode) indicates that the library imf is liked twice:

Intel(R) oneAPI DPC++/C++ Compiler 2022.1.0 (2022.1.0.20220316)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /remote/public/linux/opt/intel/oneapi-2022.2.0.262/compiler/2022.1.0/linux/bin-llvm
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10
Candidate multilib: .;@m64
Selected multilib: .;@m64
"/bin/ld" -z relro --hash-style=gnu --eh-frame-hdr -m elf_x86_64 -shared -o bld/ulfborg/final/default/lib/pybrid/3.10/unsigned/fragments.cpython-310-x86_64-linux-gnu.so /lib/x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/10/crtbeginS.o -L/remote/public/linux/opt/intel/oneapi-2022.2.0.262/compiler/2022.1.0/linux/bin-llvm/../compiler/lib/intel64_lin -L/remote/public/linux/opt/intel/oneapi-2022.2.0.262/compiler/2022.1.0/linux/bin-llvm/../lib -L/remote/public/linux/opt/intel/oneapi-2022.2.0.262/compiler/2022.1.0/linux/bin-llvm/../compiler/lib/intel64_lin -L/usr/lib/gcc/x86_64-linux-gnu/10 -L/usr/lib/gcc/x86_64-linux-gnu/10/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-linux-gnu/10/../../.. -L/remote/public/linux/opt/intel/oneapi-2022.2.0.262/compiler/2022.1.0/linux/bin-llvm/../lib -L/lib -L/usr/lib -L/remote/public/linux/opt/intel/oneapi-2022.2.0.262/compiler/2022.1.0/linux/compiler/lib/intel64_lin -L/remote/public/linux/opt/intel/oneapi-2022.2.0.262/compiler/2022.1.0/linux/lib --version-script=/home/ulfw/mosekprj/dev/bld/ulfborg/final/default/fusion/pybrid/mosek-py3.def bld/ulfborg/final/default/src/pybrid/3.10/mosek-py3.os --start-group -limf -lm -ldl --end-group -Bstatic -lsvml -Bdynamic -Bstatic -lirng -Bdynamic -lstdc++ -Bstatic -limf -Bdynamic -lm -lgcc_s -lgcc -Bstatic -lirc -Bdynamic -ldl -lgcc_s -lgcc -lc -lgcc_s -lgcc -Bstatic -lirc_s -Bdynamic /usr/lib/gcc/x86_64-linux-gnu/10/crtendS.o /lib/x86_64-linux-gnu/crtn.o

 As far as I can see, what happens is that `-limf` is injected before `-lm` without `-Bstatic`, and then later again, but with a preceding `-Bstatic`. This was exactly the same issue we saw earlier.

0 Kudos
Reply