topic I have had success on Linux in Intel® Fortran Compiler

Hiding symbols in dynamic symbol table: Linux .so

rorban — Fri, 27 Sep 2019 05:33:41 GMT

In an old post, I asked whether it was possible to get the functionality of iFort Windows DLLEXPORT in Linux, where DLLEXPORT exposes only functions that are needed by an external caller. One reply suggested the Linux STRIP command, which removes static symbols. However, after using this command, I still see thousands of symbols in the "Dynamic symbol" and "relocation" tables in the .so file, and I would prefer that almost all of these remain private.

https://akkadia.org/drepper/dsohowto.pdf

page 22, section 2.5.5 proposes solving this by using Export Maps at the link stage, and shows the syntax for applying such a map file at the link stage when building a project using gcc. I have two questions:

(1) Is it possible to adapt this method to Intel Fortran for Linux, and if so, what is the syntax?

In the example, they use a linker option --version-script and show a build command line example

$ gcc -shared -o -foo.so foo.c -fPIC \ W1, --version-script=foo.map

(2) What damage can I do by removing what seem to be private symbols from the dynamic symbol table and the relocation tables? (That is, removing function names that will not be called by the external caller, along with the internal variables in these private functions and subroutines. Or do I have to retain all of them? Or a subset?)

Finally, I have to remark that if the Intel team implemented the equivalent of DLLEXPORT in the Linux compiler, I would certainly find it useful.

Thanks in advance for any insight.

The compiler can't do

Steve_Lionel — Fri, 27 Sep 2019 13:43:30 GMT

The compiler can't do anything about this - it's simply the way shared libraries work on Linux.

Quote:Steve Lionel (Ret.)

rorban — Fri, 27 Sep 2019 18:47:28 GMT

Steve Lionel (Ret.) (Blackbelt) wrote:
The compiler can't do anything about this - it's simply the way shared libraries work on Linux.

To clarify my question -- Does the iFort compiler package for Linux use the gcc linker, and if so, can it support the --version-script linker option?

I have had success on Linux

Greg_T_ — Fri, 27 Sep 2019 21:11:15 GMT

I have had success on Linux using the option: --version-script=makeexportlist.txt

Where my "makeexportlist.txt" file lists the subroutine names that I want to export (such as "mySub1" and "mySub2") and hides the rest of the subroutine names. That file has the format:

{
global: mySub1; mySub2;
local: *;
};

References that were useful for me:

https://www.gnu.org/software/gnulib/manual/html_node/LD-Version-Scripts.html

https://www.gnu.org/software/gnulib/manual/html_node/Exported-Symbols-of-Shared-Libraries.html

Is this information what you're looking for?

Regards, Greg

Quote:Greg T. wrote:

rorban — Fri, 27 Sep 2019 22:26:24 GMT

Greg T. wrote:
I have had success on Linux using the option: --version-script=makeexportlist.txt

Hi Greg -- This is what I am trying to do, and I am asking how to make this syntax work on the iFort command line.

In Linux I'm using Code:Blocks and I tried adding --version-script=makeexportlist.txt to the Linker Settings>Other LInker Options window. This results in Code:Blocks just appending --version-script=makeexportlist.txt to the end of the iFort command line generated by Code:Blocks, and when I build the project, iFort does not know what to do with this argument and emits a message that it is ignoring it.

So I am looking for the syntax (if it is possible) to make this work on the iFort command line such that the linker receives this command and acts on it (assuming that iFort is using the gcc linker).

Yes, ifort uses the gcc

Steve_Lionel — Sat, 28 Sep 2019 00:47:44 GMT

Yes, ifort uses the gcc linker "ld".

I found the syntax and got -

rorban — Sat, 28 Sep 2019 02:55:25 GMT

I found the syntax and got --version-script= working: Add to the iFort command line

-Wl,--version-script=makeexportlist.txt

The next step is to check to see if I removed too much from the .so.