1 interface_check(1) User Commands interface_check(1)
2
3
4
5 NAME
6 interface_check - check shared object interfaces
7
8 SYNOPSIS
9 interface_check [-hIo] [-c vertype_module] [-E errfile] [-e exfile] [-f
10 listfile] [-i intffile] [-w outdir] file | dir, ...
11
12 DESCRIPTION
13 The interface_check command attempts to check a number of ELF
14 versioning attributes for consistency with common build rules and
15 practices. In addition, a complete breakdown of the file's version
16 definitions can be captured using the -i option, and the interface
17 description file created can be used with interface_cmp to audit the
18 versioning evolution of a software product. These interface
19 description files reflect the association of the shared object's global
20 symbols with recorded version definitions.
21
22 interface_check is typically called from nightly(1) when the -A option
23 is in effect. In this case the shared objects under the associated
24 proto area ($ROOT) are examined. interface_check can also be run
25 standalone against any set of dynamic objects.
26
27 interface_check uses elfdump(1) and pvs(1) to check file naming
28 standardization, and versioning consistency. These check are carried
29 out for the following reasons:
30
31 o A shared object should exist with a versioned filename. A
32 versioned filename commonly takes the form of a .so suffix followed
33 by a version number. For example, /usr/lib/libc.so.1 is the shared
34 object representation of version one of the standard C library made
35 available to the runtime environment. A versioned filename allows
36 for a change in the exported interface of the shared object over a
37 series of software releases. A shared object that doesn't exist as
38 a versioned filename is displayed as:
39
40 foo.so: does not have a versioned name
41
42 o Versions should be defined within a shared object both to clarify
43 its public or private use, and to explicitly define the interfaces
44 that it makes available. The reduction in object size, and
45 relocation cost created by reducing non-interface symbols to locals
261
262 The -I option is primary used for debugging interface_check and
263 interface_cmp.
264
265 EXAMPLES
266 The following example uses interface_check to generate an interface
267 database for a workspace:
268
269 % mkdir $SRC/ELF-data.$MACH
270 % interface_check -w $SRC/ELF-data.$MACH -E interface.err
271 -i interface $ROOT
272 % ls -1R $SRC/ELF
273 interface
274 interface.err
275
276 FILES
277 $CODEMGR_WS/exception_list/interface_check
278 /opt/onbld/etc/exception_list/interface_check
279
280 SEE ALSO
281 find_elf(1), interface_cmp(1), ld(1), ldd(1), elfdump(1), pvs(1).
282
283
284
285 25 March 2010 interface_check(1)
|
1 interface_check(1ONBLD) illumos Build Tools interface_check(1ONBLD)
2
3
4
5 NAME
6 interface_check - check shared object interfaces
7
8 SYNOPSIS
9 interface_check [-hIo] [-c vertype_module] [-E errfile] [-e exfile] [-f
10 listfile] [-i intffile] [-w outdir] file | dir, ...
11
12 DESCRIPTION
13 The interface_check command attempts to check a number of ELF
14 versioning attributes for consistency with common build rules and
15 practices. In addition, a complete breakdown of the file's version
16 definitions can be captured using the -i option, and the interface
17 description file created can be used with interface_cmp to audit the
18 versioning evolution of a software product. These interface
19 description files reflect the association of the shared object's global
20 symbols with recorded version definitions.
21
22 interface_check is typically called from nightly(1ONBLD) when the -A
23 option is in effect. In this case the shared objects under the
24 associated proto area ($ROOT) are examined. interface_check can also
25 be run standalone against any set of dynamic objects.
26
27 interface_check uses elfdump(1) and pvs(1) to check file naming
28 standardization, and versioning consistency. These check are carried
29 out for the following reasons:
30
31 o A shared object should exist with a versioned filename. A
32 versioned filename commonly takes the form of a .so suffix followed
33 by a version number. For example, /usr/lib/libc.so.1 is the shared
34 object representation of version one of the standard C library made
35 available to the runtime environment. A versioned filename allows
36 for a change in the exported interface of the shared object over a
37 series of software releases. A shared object that doesn't exist as
38 a versioned filename is displayed as:
39
40 foo.so: does not have a versioned name
41
42 o Versions should be defined within a shared object both to clarify
43 its public or private use, and to explicitly define the interfaces
44 that it makes available. The reduction in object size, and
45 relocation cost created by reducing non-interface symbols to locals
261
262 The -I option is primary used for debugging interface_check and
263 interface_cmp.
264
265 EXAMPLES
266 The following example uses interface_check to generate an interface
267 database for a workspace:
268
269 % mkdir $SRC/ELF-data.$MACH
270 % interface_check -w $SRC/ELF-data.$MACH -E interface.err
271 -i interface $ROOT
272 % ls -1R $SRC/ELF
273 interface
274 interface.err
275
276 FILES
277 $CODEMGR_WS/exception_list/interface_check
278 /opt/onbld/etc/exception_list/interface_check
279
280 SEE ALSO
281 find_elf(1ONBLD), interface_cmp(1ONBLD), ld(1), ldd(1), elfdump(1),
282 pvs(1).
283
284
285
286 25 March 2010 interface_check(1ONBLD)
|