Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
26734 Discussions

Hiding symbols in dynamic symbol table: Linux .so

rorban
Beginner
643 Views

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.

0 Kudos
6 Replies
Steve_Lionel
Black Belt Retired Employee
643 Views

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

rorban
Beginner
643 Views

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?

Greg_T_
Valued Contributor I
643 Views

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

rorban
Beginner
643 Views

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

Steve_Lionel
Black Belt Retired Employee
643 Views

Yes, ifort uses the gcc linker "ld".

rorban
Beginner
643 Views

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.

Reply