How to hide __svml_* from a shared libary?

[a_zhaogtisoft_com]

I would like to hide __svml_exp2 and  __svml_log2 from a shared libary I build with ifort, currently the both are exposed:

 # nm -A libgtiusr74_dp.so | grep __svml
libgtiusr74_dp.so:000af9a0 T __svml_exp2
libgtiusr74_dp.so:000b00c0 t __svml_exp2.A
libgtiusr74_dp.so:000afd10 t __svml_exp2.L
libgtiusr74_dp.so:000afa70 t __svml_exp2.N
libgtiusr74_dp.so:000b0260 t __svml_exp2.R
libgtiusr74_dp.so:000af9f0 T __svml_log2
libgtiusr74_dp.so:000b0900 t __svml_log2.A
libgtiusr74_dp.so:000b0500 t __svml_log2.L
libgtiusr74_dp.so:000b0ad0 t __svml_log2.R
libgtiusr74_dp.so:000afa30 T __svml_pow2
libgtiusr74_dp.so:000b2b00 t __svml_pow2.A
libgtiusr74_dp.so:000b1ac0 t __svml_pow2.L
libgtiusr74_dp.so:000b3b50 t __svml_pow2.R

The libgtiusr74_dp.so is linked with "ifort -static-intel -shared -Wl,--no-undefined".

Is there a way to do this?

Here are some background:

Our solver exec (mostly f90 codes) would be linked to libgtiusr74_dp.so; and our customer can build their own version, and substitute ours with their own build. Because both __svml_exp2 and  __svml_log2 are exposed (the 'T' attribute from nm output), when main solver is linked with libgtiusr74_dp.so, the main exec actually will depend on .so to resolve the 2 symbols. (No, we do not ship Intel runtime .so for our customers, we have got seriously burnt by that when using ifort 8, 8.1 and later 9 with our itanium port because of some undocumented file deployment - and we always use -static-intel option to avoid distributing any Intel runtimes.)

Now when customer modified the source codes to build their own libgtiusr74_dp.so, they may NOT use the exp or log functions, and their version of .so may have either or both symbols missing. Upon substituting our default .so with their build, the main solver will fail to unresolved symbols of either __svml_exp2 or __svml_log2.

Is there some linker options that can force the 2 symbols to have 't' instead of 'T'? That could be the easiest way to fix this.

Any suggestion?

[TimP]

I suspect that once you have included static svml functions in your own .so, you will be limited to static linking against svml.  Certainly, it might be interesting if there are other possibilities (besides splitting the .so so that the static modules could be excluded).

[a_zhaogtisoft_com]

In dealing with one of the customer issue, I actually ask the customer to link their version of libgtiusr74_dp.so with "-Bdynamic -lsvml".  This will link the libsvml.so, and as long as they put libsvml.so together with their own libgtiusr74_dp, the issue will be gone.

But I still think this is a hack, not a solution. In the case of customer having a different ifort version for building their own libgtiusr74_dp.so, similar issues have happened in other Intel runtime libraries as well.

[Kenneth_C_Intel]

Would compiling with -nolib-inline be a solution that would work for you? You can find more information on it here

http://software.intel.com/sites/products/documentation/doclib/iss/2013/compiler/cpp-lin/GUID-C9290B3F-2B8E-428A-BB6A-37AA242A51B4.htm

-Ken