Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29273 Обсуждение

Hiding symbols in dynamic symbol table: Linux .so

rorban
Начинающий
4 468Просмотр.

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 баллов
6 Ответы
Steve_Lionel
Почетный участник III
4 468Просмотр.

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

rorban
Начинающий
4 468Просмотр.

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_
Ценный участник I
4 468Просмотр.

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
Начинающий
4 468Просмотр.

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
Почетный участник III
4 468Просмотр.

Yes, ifort uses the gcc linker "ld".

rorban
Начинающий
4 468Просмотр.

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.

Ответить