How to hide __svml_* from a shared libary?

How to hide __svml_* from a shared libary?

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 | grep __svml T __svml_exp2 t __svml_exp2.A t __svml_exp2.L t __svml_exp2.N t __svml_exp2.R T __svml_log2 t __svml_log2.A t __svml_log2.L t __svml_log2.R T __svml_pow2 t __svml_pow2.A t __svml_pow2.L t __svml_pow2.R

The 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; 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, 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, 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?

4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

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).

In dealing with one of the customer issue, I actually ask the customer to link their version of with "-Bdynamic -lsvml".  This will link the, and as long as they put 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, similar issues have happened in other Intel runtime libraries as well.

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


Leave a Comment

Please sign in to add a comment. Not a member? Join today