Capabilities allow you to extend the functionality of generic objects with platform, machine or hardware specific instances. These instances typically target new or more specialized systems. However, over time many capabilities that might once have been thought of as specialized, become more common, and may become available on all the systems on which your code executes. It is therefore necessary to revisit these details from time to time, and revise objects to keep the capabilities current.
Capabilities instances should be monitored to ensure they have not become redundant. If a capabilities instance becomes available on all the systems your code is targeted towards, then maintaining the instance is pointless. The base object version of the capability instance should be replaced with the capability instance.
The link-editor can not assume that the platform on which you build your software is the same platform on which the software will be executed. Therefore, the link-editor can not provide a thorough validation of the relevance of any instance. However, if the symbol capabilities of an object do not extend the object capabilities of the object, a warning diagnostic can be produced.
While creating the following object, foo.so, both object capabilities and symbol capabilities are detected, and the symbol capabilities do not extend the capabilities of the base object.
$ cc -o foo.so -G -Kpic foo.o foo.cap.o
ld: warning: file foo.cap.o: section [3].SUNW_cap: symbol capabilities \
do not extend object capabilities and are redundant
(object: CA_SUNW_HW_1 0x800 [ SSE ]);
(symbol: CA_SUNW_HW_1 0x80 [ AMD_MMX ]);
As foo.so can not be loaded unless SSE is available, and the SSE capability is greater than AMD_MMX, then the presence of SSE implies the presence of AMD_MMX. Hence the AMD_MMX instance is redundant. The base object version of the capability instance should be replaced with the capability instance.