Filter
Top Products
60 Chapter 3
Linker Tasks
Using Linker commands
• The program calls shl_definesym to define a symbol that is already
defined in a library that was loaded at program startup.
If such a program is linked with -B immediate, references to symbols
will be bound at program startup, regardless of whether duplicate
symbols are created later by shl_load or shl_definesym.
But what happens when, to take advantage of the performance benefits
of deferred binding, the same program is linked with -B deferred? If a
duplicate, more visible symbol definition is created prior to referencing
the symbol, it binds to the more visible definition, and the program
might run incorrectly. In such cases, -B restricted is useful, because
symbols bind the same way as they do with -B immediate, but actual
binding is still deferred.
Improving Shared Library Performance with
-B symbolic
The linker supports the -B symbolic option which optimizes call paths
between procedures when building shared libraries. It does this by
building direct internal call paths inside a shared library. In linker
terms, import and export stubs are bypassed for calls within the
library.
A benefit of -B symbolic is that it can help improve application
performance and the resulting shared library will be slightly smaller.
The -B symbolic option is useful for applications that make a lot of
calls between procedures inside a shared library and when these same
procedures are called by programs outside of the shared library.
NOTE The -B symbolic option applies only to function, but not variable,
references in a shared library.
Example Using -B symbolic
For example, to optimize the call path between procedures when building
a shared library called lib1.sl, use -B symbolic as follows:
$ ld -B symbolic -b func1.o func2.o -o lib1.sl