Ideally, the compiler can generate objects that are identified with symbol capabilities. If the compiler can not create symbol capabilities, the link-editor offers a solution.
A relocatable object that defines object capabilities can be transformed into a relocatable object that defines symbol capabilities using the link-editor. Using the link-editor –z symbolcap option, any capability data section is converted to define symbol capabilities. All global functions within the object are converted into local functions, and are associated with symbol capabilities. All global initialized data items are converted to local data items, and are associated with symbol capabilities. These transformed symbols are appended with any capability identifier specified as part of the object capabilities group. If a capability identifier is not defined, a default group name is appended.
For each original global function or initialized data item, a global reference is created. This reference is associated to any relocation requirements, and provides for binding to a default, global symbol when this object is finally combined to create a dynamic object.
In the following example, a x86 relocatable object contains two global functions foo() and bar(). This object has been compiled to require the MMX and SSE hardware capabilities. In these examples, the capabilities group has been named with a capabilities identifier entry. This identifier name is appended to the transformed symbol names. Without this explicit identifier, the link-editor appends a default capabilities group name.
$ elfdump -H foo.o Capabilities Section: .SUNW_cap Object Capabilities: index tag value  CA_SUNW_ID sse,mmx  CA_SUNW_HW_1 0x840 [ SSE MMX ] $ elfdump -s foo.o | egrep "foo|bar"  0 0x21 FUNC GLOB D 0 .text foo  0x24 0x1e FUNC GLOB D 0 .text bar $ elfdump -r foo.o | fgrep foo R_386_PLT32 0x38 .rel.text foo
This relocatable object can now be transformed into a symbol capabilities relocatable object.
$ ld -r -o foo.1.o -z symbolcap foo.o $ elfdump -H foo.1.o Capabilities Section: .SUNW_cap Symbol Capabilities: index tag value  CA_SUNW_ID sse,mmx  CA_SUNW_HW_1 0x840 [ SSE MMX ] Symbols: index value size type bind oth ver shndx name  0 0x21 FUNC LOCL D 0 .text foo%sse,mmx  0x24 0x1e FUNC LOCL D 0 .text bar%sse,mmx $ elfdump -s foo.1.o | egrep "foo|bar"  0 0x21 FUNC LOCL D 0 .text foo%sse,mmx  0x24 0x1e FUNC LOCL D 0 .text bar%sse,mmx  0 0 FUNC GLOB D 0 UNDEF foo  0 0 FUNC GLOB D 0 UNDEF bar $ elfdump -r foo.1.o | fgrep foo R_386_PLT32 0x38 .rel.text foo
This object can now be combined with other objects containing instances of the same functions, associated with different symbol capabilities, to produce a dynamic object. In addition, a default instance of each function, one that is not associated with any symbol capabilities, must be provided to lead each capabilities family. This default instance provides for all external references, and ensures that an instance of the function is available on any system.
At runtime, any references to foo() and bar() are directed to the lead instances. However, the runtime linker selects the best symbol capabilities instance if the system accommodates the appropriate capabilities.
Archive libraries usually contain a collection of relocatable objects. The link-editor can extract individual relocatable objects to resolve unresolved symbol references. See Archive Processing.
If a family of capabilities relocatable objects were added to an archive, any reference to the lead capability symbol only extracts the generic relocatable object that defines that symbol. No other capabilities objects are extracted.
If capabilities objects are required to be deployed using an archive library, a single capability family relocatable object should be created. Combine any capabilities objects, and any generic object containing the capabilities lead symbol, into one relocatable object. Add this single object, containing the entire capabilities family collection, to the archive.
$ ld -r -o all.foo.o foo.o foo.1.o foo.2.o .... $ ar -cr libfoo.o all.foo.o