-static-intel does not have expected effect

[Chen-Chau_C_]

I had several problems in the linking.  After studying several posting, I changed to use icpc for C++ specific linking and that got rid of most of my problems.

The remaining problem is I am build a program.  Its normal operation requires dynamic loading of different so based on run-time flags.  Therefore -ldl was used at the end of line.

However,. the portion needed from Intel library (libimf and libintlc) is also "linked in" only dynamically.  I must have them showing up somewhere in my $LD_LIBRARY_PATH to get the program to launch properly.  While there may be internal variations within these two libraries themselves, the different so my main program needs to load have the same needs from the intel libraries.  So I hope there is a way I can get these two linked in statically while keeping the rest of the program structure as before.  As is obvious from the quoted line, there are several other components were linked in statically.  I know -static cannot be used as it conflicts with -ldl.  Intuitively -static-intel is the answer, but I am not getting the hoped for effect.  

icpc -static-intel -L/local/scratch/chucc/opt/intel/composerxe/lib/intel64 -limf -L/local/scratch/chucc/intel.3/tools/simulator/bin/v5/lnx64 -L../../arch_v5/src/bin/v5/lnx64 -o /local/scratch/chucc/intel.3/tools/simulator/bin/v5/lnx64/../../hexagon-sim /local/scratch/chucc/intel.3/tools/simulator/build/v5/lnx64/src/main.o /local/scratch/chucc/intel.3/tools/simulator/build/v5/lnx64/src/clmain.o /local/scratch/chucc/intel.3/tools/simulator/build/v5/lnx64/src/main_utils.o /local/scratch/chucc/intel.3/tools/simulator/build/v5/lnx64/src/version.o ../libs/utils/bin/lnx64//libutils.a ../libs/utils/bin/lnx64//libelf.a /local/scratch/chucc/intel.3/tools/simulator/bin/lnx64/libwrapper.a -ldl

Great thanks for your help.

[Sukruth_H_Intel]

Hi, "-static-intel" option causes Intel-provided libraries to be linked in statically. If you specify option static-intel and any of the Intel-provided libraries have no static version, a diagnostic will be displayed. So do you see any warning when you use -static-intel, saying "static library not available"? Also i think you can try the following way:- Since you want these 2 libs to be linked statically, Provided you have set the icc:- "icpc source.cpp -Wl,-Bstatic -limf -lintlc -Wl,-Bdynamic ". All libraries on the command line following option -Bstatic are linked statically until the end of the command line or until a -Bdynamic option is encountered. The -Bdynamic option enables dynamic linking of libraries. Please do let me know if this helps. Regards, Sukruth H V

[Chen-Chau_C_]

when I studied the log, I did not see any such warning, but I may well be wrong. For what I have checked, there is NO static counter-part for libintcl.so.5. so there is a good chance I missed something. Your second point is definitely worth a try. I need to crunch out some numbers first, then I will definitely try out and report. Thanks!!

[Sukruth_H_Intel]

Hi, Sure even i was unable to find the static version of the libintcl. Please do let me know the results after your try. Regards, Sukruth H V

[Chen-Chau_C_]

Have obtained several observations, not all of them making sense to me, so I assume I still have some operational mistakes I don't know about. (1) -static-intel has no effect, I need -Wl,-Bstatic to link in libimf statically, but I cannot always achieve this even with repeated make clean and make. For my last two make-clean-make cycles, I was able to maintain libimf.so and libintcl.so.5 off my LD_LIBRARY_PATH and still maintain performance advantage (faster run) (2) for my main program (the part that will use dlopen() to load other .so) when I use gnu ldd on it, I see the following I did not use -lm and I am surprised that with libimf.a linked (if that is the case) why I still need libm.so. But it maybe that libimf.so does not fully replace, but rather supplement libm.so. So maybe it is a sign that I truly don't need any intel components through DLL hence the static link is working ? linux-vdso.so.1 => (0x00007ffff25ff000) libdl.so.2 => /lib64/libdl.so.2 (0x00002b1e7260e000) libm.so.6 => /lib64/libm.so.6 (0x00002b1e72712000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002b1e72868000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002b1e72a66000) libc.so.6 => /lib64/libc.so.6 (0x00002b1e72b73000) /lib64/ld-linux-x86-64.so.2 (0x0000555555554000) (3) to get the above results, I did use the suggested way of "-Wl,-Bstatic" first, followed by path to intel libs and -limf, and other static lib or obj files I have. Then finally "-Wl,-Bdynamic -ldl", adding -static-intel in various location has no effects, but taking out -Wlm-Bstatic pretty much means I must have libimf.so and libintcl.so.5 in my LD_LIBRARY_PATH (4) for all combinations I tried, I cannot use -lintcl and still get successful linkage. So this lib entity is different from other lib entities I know/used before. Don't know what it is. However, whenever I need libimf.so to be present, I also need this one. If I don't need libimf.so to be present in my LD_LIBRARY_PATH, then I have never needed this one to be present, either. (5) a different matter but accidentally found. Currently my main program is roughly 400KB and the main .so (will be opened through dlopen()) is 2254KB. I use icpc only for linking, while using icc -x c++ to compile all C/C++ code for about half my source code (these are C code with tight relationship with C++ code or even directly has C++ keywords in them), and icc without -x for the other half of my source code (these are known to be written as pure C and will be able to be linked into some other C-only main programs). Interestingly, the sizes are roughly the same when I must have libimf.so and libintcl.so.5 in my LD_LIBRARY_PATH. Hence make me wonder how I can verify I have truly linked in the Intel components statically. NOW, if the half of the source code that is really C/C++ are compiled with icpc (but everything else the same including the presence of -x c++ flag) and linking still using icpc, I will get a main program size of 800 KB and the library about 12xx KB, and I don't need intel .so, BUT the performance is bad (losing to our standard gcc build) Intuitively "icc -x c++ a.c" should be the same as "icpc a.c" but the code sizes are really a lot different, most likely it means different components are linked in. I am puzzled about this. I am however, grateful that you showed me a way to link in the two intel components statically. What still worries me a bit is I am not sure I can really mechanically reproduce the symptoms I reported above. I plan to wipe out the binary area and start full repetition tomorrow to make sure I can reproduce what I can do today (using a new shell as well) If you can shed some light on the above observations or even use them to detect/suggest where I might have done wrong, it would be great. Thanks for the help.