- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Reminder:
Has the solution provided helped? Is your issue resolved? Please let us know if the issue still persists.
Best Regards,
Shanmukh.SS
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page