Print this page
6205 onbld manuals should be declared as 1onbld
Reviewed by: Dan McDonald <danmcd@omniti.com>
Reviewed by: Josef Sipek <jeffpc@josefsipek.net>
| Split |
Close |
| Expand all |
| Collapse all |
--- old/usr/src/tools/scripts/check_rtime.1
+++ new/usr/src/tools/scripts/check_rtime.1onbld
1 1 .\" Copyright (c) 2001, 2010, Oracle and/or its affiliates. All rights reserved.
2 2 .\"
3 3 .\" CDDL HEADER START
4 4 .\"
5 5 .\" The contents of this file are subject to the terms of the
6 6 .\" Common Development and Distribution License (the "License").
7 7 .\" You may not use this file except in compliance with the License.
8 8 .\"
9 9 .\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
10 10 .\" or http://www.opensolaris.org/os/licensing.
11 11 .\" See the License for the specific language governing permissions
|
↓ open down ↓ |
11 lines elided |
↑ open up ↑ |
12 12 .\" and limitations under the License.
13 13 .\"
14 14 .\" When distributing Covered Code, include this CDDL HEADER in each
15 15 .\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
16 16 .\" If applicable, add the following below this CDDL HEADER, with the
17 17 .\" fields enclosed by brackets "[]" replaced with your own identifying
18 18 .\" information: Portions Copyright [yyyy] [name of copyright owner]
19 19 .\"
20 20 .\" CDDL HEADER END
21 21 .\"
22 -.TH check_rtime 1 "09 March 2010"
22 +.TH check_rtime 1ONBLD "09 March 2010"
23 23 .SH NAME
24 24 .I check_rtime
25 25 \- check ELF runtime attributes
26 26 .SH SYNOPSIS
27 27 \fBcheck_rtime [-imosv] [-D depfile | -d depdir] [-E errfile] [-e exfile] [-f listfile] [-I infofile] [-w outdir] file | dir, ...\fP
28 28 .LP
29 29 .SH DESCRIPTION
30 30 .IX "OS-Net build tools" "check_rtime" "" "\fBcheck_rtime\fP"
31 31 .LP
32 32 .I check_rtime
33 33 attempts to check a number of ELF runtime attributes
34 34 for consistency with common build rules.
35 35 These checks involve running \fBldd(1)\fP and
36 36 \fBelfdump(1)\fP against a family of dynamic objects.
37 37 A dynamic object can be defined explicitly as a \fIfile\fP
38 38 or multiple dynamic objects can be located under the directory \fIdir\fP.
39 39 .LP
40 40 .I check_rtime
41 -is typically called from \fBnightly(1)\fP when the \fB-r\fP
41 +is typically called from \fBnightly(1ONBLD)\fP when the \fB-r\fP
42 42 option is in effect. In this case the dynamic objects under
43 43 the associated \fIproto\fP area (\fB$ROOT\fP) are checked.
44 44 .I check_rtime
45 45 can also be run standalone against any set of dynamic objects.
46 46 .LP
47 47 .I check_rtime
48 48 uses \fBldd(1)\fP to verify dependencies. This implies that
49 49 by default any object inspected will bind to its dependencies
50 50 as they are found in the \fBunderlying\fP system. Use of the \fB-D\fP, \fB-d\fP
51 51 option, or the existence of the environment variables
52 52 \fB$CODEMGR_WS/$ROOT\fP instruct
53 53 .I check_rtime
54 54 to establish an alternative dependency mapping using
55 55 runtime configuration files generated with \fBcrle(1)\fP.
56 56 .LP
57 57 .I check_rtime
58 58 uses \fBldd(1)\fP to completely relocate any dynamic
59 59 object and thus detect missing dependencies, unsatisfied
60 60 symbol relocations, unused and unreferenced dependencies. These checks
61 61 are carried out for the following reasons:
62 62 .TP 4
63 63 \(bu
64 64 An object that cannot find its dependencies may fail to load
65 65 at runtime. This error condition often goes unnoticed
66 66 because the existing use of the object is as a dependency itself,
67 67 and the objects' dependencies are already satisfied by the
68 68 caller. However, if the object itself is unable to satisfy its
69 69 dependencies, its use in new environments may be compromised.
70 70 .sp
71 71 A missing or erroneous \fBrunpath\fP is the typical reason why
72 72 an object can not locate its dependencies. Use of the link-editors
73 73 \fB-zdefs\fP option when building a shared object ensures required
74 74 dependencies are established. This flag is inherited from
75 75 \fB$(DYNFLAGS)\fP in \fIlib/Makefile.lib\fP. Missing dependencies
76 76 are displayed as:
77 77 .sp
78 78 .RS 6
79 79 foo: bar.so.1 => (file not found) <no -zdefs?>
80 80 .RE
81 81 .TP
82 82 \(bu
83 83 Unsatisfied symbol relocations indicate that some thread of
84 84 execution through the object will fail when it is unable to
85 85 locate a referenced symbol.
86 86 .sp
87 87 A missing, or mismatched version of a dependency is the typical
88 88 reason for unsatisfied symbol relocations (see missing dependency
89 89 discussion above). Unsatisfied symbol relocations are displayed as:
90 90 .sp
91 91 .RS 6
92 92 foo: symbol not found: bar <no -zdefs?>
93 93 .RE
94 94 .RS 4
95 95 .sp
96 96 Note: Shared objects can make reference to symbol definitions
97 97 that are expected to be defined by the caller. To indicate that
98 98 such symbols are not undefined in the usual sense, you must
99 99 specify these symbols in a \fImapfile\fP, using the \fBEXTERN\fP
100 100 or \fBPARENT\fP symbol attribute. Without these symbol attributes,
101 101 \fBldd(1)\fP is unable to determine the symbols special nature, and
102 102 .I check_rtime
103 103 will report these symbols as undefined.
104 104 .RE
105 105 .TP
106 106 \(bu
107 107 Unused dependencies are wasteful at runtime, as they take time to
108 108 load and relocate, but will not be used by the calling object. They
109 109 also result in unnecessary processing at link-edit time.
110 110 .sp
111 111 Dependency lists (typically defined via \fB$(LDLIBS)\fP)
112 112 that have been yanked-and-put
113 113 between \fIMakefiles\fP without verifying their need, are a typical
114 114 reason why unused dependencies exist. Unused dependencies are
115 115 displayed as:
116 116 .sp
117 117 .RS 6
118 118 foo: unused object=bar.so.1 <remove lib or -zignore?>
119 119 .RE
120 120 .TP
121 121 \(bu
122 122 Unreferenced dependencies are also wasteful at runtime, although not
123 123 to the extent of unused dependencies. They also result in unnecessary
124 124 processing at link-edit time.
125 125 .sp
126 126 Unreferenced dependency removal guards against a dependency becoming
127 127 unused when combined with
128 128 different objects, or as the other object dependencies evolve.
129 129 Unreferenced dependencies are displayed as:
130 130 .sp
131 131 .RS 6
132 132 foo: unreferenced object=bar.so.1; \\
133 133 .br
134 134 unused dependency of libfoo.so.1 \\
135 135 .br
136 136 <remove lib or -zignore?>
137 137 .RE
138 138 .RS 4
139 139 .sp
140 140 See also the section ENVIRONMENT VARIABLES.
141 141 .RE
142 142 .TP
143 143 \(bu
144 144 Unused search paths are wasteful at runtime.
145 145 Unused search paths are displayed as:
146 146 .sp
147 147 .RS 6
148 148 foo: unused search path=/usr/foo/lib \\
149 149 .br
150 150 (RUNPATH/RPATH from file libfoo.so.1) \\
151 151 .br
152 152 <remove search path?>
153 153 .RE
154 154 .LP
155 155 .I check_rtime
156 156 uses \fBelfdump(1)\fP to look for a concatenated relocation
157 157 section in shared objects, the existence of text relocations,
158 158 whether debugging or symbol table information exists, whether
159 159 applications have a non-executable stack defined, duplicate
160 160 entries in the symbol sorting sections, and for direct bindings.
161 161 These checks are carried out for the following reasons:
162 162 .TP 4
163 163 \(bu
164 164 A concatenated relocation section (\fI.SUNW_reloc\fP)
165 165 provides optimal symbol table
166 166 access at runtime, and thus reduces the overhead of relocating
167 167 the shared object. In past releases, the link-edit of a dynamic object with
168 168 the \fB-z combreloc\fP option was required to generate a combined
169 169 relocation section. However, with the integration of 6642769, this section
170 170 combination is a default behavior of the link-editor.
171 171 .sp
172 172 In past releases, not inheriting \fB$(DYNFLAGS)\fP from
173 173 \fIlib/Makefile.lib\fP was the typical reason for not having a
174 174 concatenated relocation section. The misguided use of the
175 175 \fB-z nocombreloc\fP option will also prevent the creation of a
176 176 concatenated relocation section. A missing concatenated relocation section
177 177 is displayed as:
178 178 .sp
179 179 .RS 6
180 180 foo: .SUNW_reloc section missing <no -zcombreloc?>
181 181 .RE
182 182 .TP
183 183 \(bu
184 184 Text relocations result in impure text segments. As text segments
185 185 are typically read-only, they can be shared between numerous processes.
186 186 If they must be updated as part of the relocation then the updated
187 187 pages become unsharable and swap space must be allocated to back
188 188 these pages. These events consume unnecessary system resources and
189 189 reduce overall system performance.
190 190 .sp
191 191 Not inheriting the \fB$(PICS)\fP
192 192 rules from \fIlib/Makefile.lib\fP is the typical reason for having
193 193 non-pic code in shared objects. Text relocations are displayed as:
194 194 .sp
195 195 .RS 6
196 196 foo: TEXTREL .dynamic tag <no -Kpic?>
197 197 .RE
198 198 .TP
199 199 \(bu
200 200 Debugging information is unnecessary in released objects. Although
201 201 extensive when compiled \fB-g\fP, small quantities of debugging
202 202 information are stored in \fI.stabs\fP sections under normal
203 203 compilations. This debugging information is geared towards aiding
204 204 debuggers locate relocatable objects associated with the dynamic
205 205 objects being debugged. As relocatable objects aren't made available
206 206 as part of a software release this information has no use.
207 207 .sp
208 208 Not inheriting the correct \fB$(LDFLAGS)\fP from \fIcmd/Makefile.cmd\fP
209 209 (which asserts \fP-s\fP), or \fB$(POST_PROCESS_SO)\fP (which asserts
210 210 \fIstrip -x\fP) are typical reasons for not removing debugging
211 211 information. Note, removal of debugging information is only enabled
212 212 for release builds. The existence of debugging information is displayed as:
213 213 .sp
214 214 .RS 6
215 215 foo: debugging sections should be deleted \\
216 216 .br
217 217 <no strip -x?>
218 218 .RE
219 219 .TP
220 220 \(bu
221 221 All objects should retain their full \fI.symtab\fP symbol table.
222 222 Although this consumes disk space, it provides for more extensive stack
223 223 tracing when debugging user applications.
224 224 .sp
225 225 Hard coding a \fI-s\fP flag with \fB$(LDFLAGS)\fP or
226 226 \fB$(DYNFLAGS)\fP is the typical
227 227 reason for symbol tables being removed.
228 228 Objects that do not contain a symbol table are displayed as:
229 229 .sp
230 230 .RS 6
231 231 foo.so.1: symbol table should not be stripped \\
232 232 .br
233 233 <remove -s?>
234 234 .RE
235 235 .TP
236 236 \(bu
237 237 Applications should have a non-executable stack defined to make
238 238 them less vulnerable to buffer overflow attacks.
239 239 .sp
240 240 Not inheriting the \fB$(LDFLAGS)\fP macro in \fIcmd/Makefile.cmd\fP
241 241 is the typical reason for not having a non-executable stack definition.
242 242 Applications without this definition are displayed as:
243 243 .sp
244 244 .RS 6
245 245 foo: application requires non-executable stack \\
246 246 .br
247 247 <no -Mmapfile_noexstk?>
248 248 .RE
249 249 .sp
250 250 .TP
251 251 \(bu
252 252 x86 applications should have a non-executable data segment defined to make
253 253 them less vulnerable to buffer overflow attacks.
254 254 .sp
255 255 Not inheriting the \fB$(LDFLAGS)\fP macro in \fIcmd/Makefile.cmd\fP
256 256 is the typical reason for not having a non-executable data definition.
257 257 Applications without this definition are displayed as:
258 258 .sp
259 259 .RS 6
260 260 foo: application requires non-executable data \\
261 261 .br
262 262 <no -Mmapfile_noexdata?>
263 263 .RE
264 264 .sp
265 265 .TP
266 266 \(bu
267 267 Solaris ELF files contain symbol sort sections used by DTrace to
268 268 map addresses in memory to the related function or variable symbols. There
269 269 are two such sections, \fI.SUNW_dynsymsort\fP for
270 270 regular symbols, and \fI.SUNW_dyntlssort\fP for thread-local
271 271 symbols. To ensure that the best names are shown for each
272 272 such address, and that the same name is given across Solaris releases,
273 273 .I check_rtime
274 274 enforces the rule that only one symbol can appear in the sort sections for
275 275 any given address.
276 276 There are two common ways in which multiple symbols
277 277 or a given address occur in the ON distribution. The first is from
278 278 code written in assembly language. The second is as a
279 279 result of using \fB#pragma weak\fP in C to create weak symbols. The
280 280 best solution to this
281 281 situation is to modify the code to avoid symbol aliasing. Alternatively,
282 282 the \fBNODYNSORT\fP mapfile attribute can be used to eliminate the unwanted
283 283 symbol.
284 284 .sp
285 285 Duplicate entries in a symbol sort section are
286 286 displayed in one of the following ways, depending on
287 287 whether the section is for regular or thread-local symbols:
288 288 .sp
289 289 .RS 6
290 290 foo: .SUNW_dynsymsort: duplicate ADDRESS: sym1, sym2
291 291 .br
292 292 foo: .SUNW_dyntlssort: duplicate OFFSET: sym1, sym2
293 293 .RE
294 294 .sp
295 295 .TP
296 296 \(bu
297 297 \fBOSNet\fP dynamic ELF objects are expected to employ direct bindings whenever
298 298 feasible. This runtime binding technique helps to avoid accidental
299 299 interposition problems, and provides a more optimal
300 300 runtime symbol search model.
301 301 .sp
302 302 Not inheriting the correct \fB$(LDFLAGS)\fP from \fIcmd/Makefile.cmd\fP,
303 303 or the correct \fB$(DYNFLAGS)\fP from \fIlib/Makefile.lib\fP, are the
304 304 typical reasons for not enabling direct bindings. Dynamic objects that
305 305 do not contain direct binding information are displayed as:
306 306 .sp
307 307 .RS 6
308 308 foo: object has no direct bindings \\
309 309 .br
310 310 <no -B direct or -z direct?>
311 311 .RE
312 312
313 313 .sp
314 314 .LP
315 315 .I check_rtime also
316 316 uses \fBelfdump(1)\fP
317 317 to display useful dynamic entry information under the \fB-i\fP option.
318 318 This doesn't necessarily indicate an error condition, but
319 319 provides information that is often useful for gatekeepers to track
320 320 changes in a release. Presently the information listed is:
321 321 .TP
322 322 \(bu
323 323 Runpaths are printed for any dynamic object. This is a historic
324 324 sanity check to insure compiler supplied runpaths (typically from \fBCC\fP)
325 325 are not recorded in any objects. Runpaths are displayed as:
326 326 .sp
327 327 .RS 6
328 328 foo: RPATH=/usr/bar/lib
329 329 .RE
330 330 .TP
331 331 \(bu
332 332 Needed dependencies are printed for any dynamic object.
333 333 In the freeware world this often helps the introducer of a new
334 334 shared object discover that an existing binary has become its
335 335 consumer, and thus that binaries package dependencies may require updating.
336 336 Dependencies are printed as:
337 337 .sp
338 338 .RS 6
339 339 foo: NEEDED=bar.so.1
340 340 .RE
341 341 .sp
342 342 .LP
343 343 .I check_rtime
344 344 uses \fBmcs(1)\fP to inspect an object's \fI.comment\fP section.
345 345 During development, this section contains numerous file identifiers
346 346 marked with the tag "\fB@(#)\fP". For release builds these sections
347 347 are deleted and rewritten under control of the \fB$(POST_PROCESS)\fP
348 348 macro to produce a common release identifier. This identifier
349 349 typically consists of three lines including a single comment starting
350 350 with the string "\fB@(#) SunOS\fP". If this common identifier isn't
351 351 found the following diagnostic is generated:
352 352 .sp
353 353 .RS 6
354 354 foo: non-conforming mcs(1) comment <no $(POST_PROCESS)?>
355 355 .RE
356 356 .sp
357 357 .LP
358 358 .I check_rtime
359 359 uses \fBpvs(1)\fP to display version definitions under the \fB-v\fP option.
360 360 Each symbol defined by the object is shown along with the version it belongs to.
361 361 Changes to the symbols defined by an object, or the versions they belong to,
362 362 do not necessarily indicate an error condition, but
363 363 provides information that is often useful for gatekeepers to track
364 364 changes in a release.
365 365 .RE
366 366 .sp
367 367 .LP
368 368 .SH OPTIONS
|
↓ open down ↓ |
317 lines elided |
↑ open up ↑ |
369 369 .LP
370 370 The following options are supported:
371 371 .TP 4
372 372 .B \-D depfile
373 373 Use \fIdepfile\fP to generate an alternative dependency mapping.
374 374 \fIdepfile\fP must be created by '\fBfind_elf -r\fP'.
375 375 The \fB-D\fP and \fB-d\fP options are mutually exclusive.
376 376 .TP
377 377 .B \-d depdir
378 378 Use \fIdepdir\fP to generate an alternative dependency mapping.
379 -\fBfind_elf(1)\fP is used to locate the ELF sharable objects for
379 +\fBfind_elf(1ONBLD)\fP is used to locate the ELF sharable objects for
380 380 which alternative mappings are required. The \fB-D\fP and \fB-d\fP options
381 381 are mutually exclusive.
382 382 .TP 4
383 383 .B \-E errfile
384 384 Direct error messages for the analyzed objects to \fIerrfile\fP instead
385 385 of stdout.
386 386 .TP 4
387 387 .B \-e exfile
388 388 An exception file is used to exclude objects from
389 389 the usual rules. See EXCEPTION FILE FORMAT.
390 390 .TP
391 391 .B \-f listfile
392 392 Normally,
393 393 .I interface_check
394 394 runs
395 395 .I find_elf
396 396 to locate the ELF objects to analyze. The \fB-f\fP option can be
397 397 used to instead provide a file containing the list of objects to
398 398 analyze, in the format produced by '\fBfind_elf -r\fP'.
399 399 .TP
400 400 .B -I infofile
401 401 Direct informational messages (\fB-i\fP, and \fB-v\fP options) for the
402 402 analyzed objects to \fIinfofile\fP instead of stdout.
403 403 .TP
404 404 .B \-i
405 405 Provide dynamic entry information. Presently only dependencies and
406 406 runpaths are printed.
407 407 .TP
408 408 .B \-m
409 409 Enable \fBmcs(1)\fP checking.
410 410 .TP
411 411 .B \-o
412 412 Produce a one-line output for each condition discovered, prefixed
413 413 by the objects name. This output style is more terse, but is
414 414 more appropriate for sorting and diffing with previous build results.
415 415 .TP
416 416 .B \-s
417 417 Determine whether \fI.stabs\fP sections exist.
418 418 .TP
419 419 .B \-v
420 420 Provide version definition information. Each symbol defined by the object
421 421 is printed along with the version it is assigned to.
422 422 .TP
423 423 .B -w outdir
424 424 Interpret the paths of all input and output files relative to \fIoutdir\fP.
425 425 .LP
426 426 .SH EXCEPTION FILE FORMAT
427 427 Exceptions to the rules enforced by
428 428 .I check_rtime
429 429 are specified using an exception file. The \fB-e\fP option is used to
430 430 specify an explicit exception file. Otherwise, if used in an activated
431 431 workspace, the default exception file is
432 432 $CODEMGR_WS/exception_list/check_rtime
433 433 if that file exists. If not used in an activated workspace, or if
434 434 $CODEMGR_WS/exception_list/check_rtime does not exist,
435 435 .I check_rtime
436 436 will use
437 437 .I /opt/onbld/etc/exception_list/check_rtime
438 438 as a fallback default exception file.
439 439 .p
440 440 To run
441 441 .I check_rtime
442 442 without applying exceptions, specify \fB-e\fP with a value of /dev/null.
443 443 .P
444 444 A '#' character at the beginning of a line, or at any point in
445 445 a line when preceded by whitespace, introduces a comment. Empty lines,
446 446 and lines containing only comments, are ignored by
447 447 .I check_rtime.
448 448 Exceptions are specified as space separated keyword, and \fBperl(1)\fP
449 449 regular expression:
450 450 .sp
451 451 .in +4
452 452 .nf
453 453 keyword perl-regex
454 454 .fi
455 455 .in -4
456 456 .sp
457 457 Since whitespace is used as a separator, the regular
458 458 expression cannot itself contain whitespace. Use of the \\s character
459 459 class to represent whitespace within the regular expression is recommended.
460 460 Before the perl regular expression is used, constructs of the form
461 461 MACH(dir) are expanded into a regular expression that matches the directory
462 462 given, as well as any 64-bit architecture subdirectory that
463 463 might be present (i.e. amd64, sparcv9). For instance, MACH(lib) will
464 464 match any of the following:
465 465 .sp
466 466 .in +4
467 467 .nf
468 468 lib
469 469 lib/amd64
470 470 lib/sparcv9
471 471 .fi
472 472 .in -4
473 473 .sp
474 474 The exceptions understood by
475 475 .I check_rtime
476 476 are:
477 477 .sp
478 478 .ne 2
479 479 .mk
480 480 .na
481 481 \fBEXEC_DATA\fR
482 482 .ad
483 483 .RS 17n
484 484 .rt
485 485 .sp
486 486 Executables that are not required to have non-executable writable
487 487 data segments
488 488 .RE
489 489
490 490 .sp
491 491 .ne 2
492 492 .mk
493 493 .na
494 494 \fBEXEC_STACK\fR
495 495 .ad
496 496 .RS 17n
497 497 .rt
498 498 .sp
499 499 Executables that are not required to have a non-executable stack
500 500 .RE
501 501
502 502 .sp
503 503 .ne 2
504 504 .mk
505 505 .na
506 506 \fBNOCRLEALT\fR
507 507 .ad
508 508 .RS 17n
509 509 .rt
510 510 .sp
511 511 Objects that should be skipped when building the alternative dependency
512 512 mapping via the \fB-d\fP option.
513 513 .RE
514 514
515 515 .sp
516 516 .ne 2
517 517 .mk
518 518 .na
519 519 \fBNODIRECT\fR
520 520 .ad
521 521 .RS 17n
522 522 .rt
523 523 .sp
524 524 Directories and files that are allowed to have no direct bound symbols.
525 525 .RE
526 526
527 527 .sp
528 528 .ne 2
529 529 .mk
530 530 .na
531 531 \fBNOSYMSORT\fR
532 532 .ad
533 533 .RS 17n
534 534 .rt
535 535 .sp
536 536 Files for which we skip checking of duplicate addresses in the
537 537 symbol sort sections.
538 538 .RE
539 539
540 540 .sp
541 541 .ne 2
542 542 .mk
543 543 .na
544 544 \fBOLDDEP\fR
545 545 .ad
546 546 .RS 17n
547 547 .rt
548 548 .sp
549 549 Objects that used to contain system functionality that has since
550 550 migrated to libc. We preserve these libraries as pure filters for
551 551 backward compatibility but nothing needs to link to them.
552 552 .RE
553 553
554 554 .sp
555 555 .ne 2
556 556 .mk
557 557 .na
558 558 \fBSKIP\fR
559 559 .ad
560 560 .RS 17n
561 561 .rt
562 562 .sp
563 563 Directories and/or individual objects to skip. Note that SKIP should be
564 564 a last resort, used only when one of the other exceptions will not suffice.
565 565 .RE
566 566
567 567 .sp
568 568 .ne 2
569 569 .mk
570 570 .na
571 571 \fBSTAB\fR
572 572 .ad
573 573 .RS 17n
574 574 .rt
575 575 .sp
576 576 Objects that are allowed to contain debugging information (stabs).
577 577 .RE
578 578
579 579 .sp
580 580 .ne 2
581 581 .mk
582 582 .na
583 583 \fBTEXTREL\fR
584 584 .ad
585 585 .RS 17n
586 586 .rt
587 587 .sp
588 588 Objects for which we allow relocations to the text segment.
589 589 .RE
590 590
591 591 .sp
592 592 .ne 2
593 593 .mk
594 594 .na
595 595 \fBUNDEF_OBJ\fR
596 596 .ad
597 597 .RS 17n
598 598 .rt
599 599 .sp
600 600 Objects that are allowed to be unreferenced.
601 601 .RE
602 602
603 603 .sp
604 604 .ne 2
605 605 .mk
606 606 .na
607 607 \fBUNDEF_REF\fR
608 608 .ad
609 609 .RS 17n
610 610 .rt
611 611 .sp
612 612 Objects that are allowed undefined references.
613 613 .RE
614 614
615 615 .sp
616 616 .ne 2
617 617 .mk
618 618 .na
619 619 \fBUNUSED_DEPS\fR
620 620 .ad
621 621 .RS 17n
622 622 .rt
623 623 .sp
624 624 Objects that are allowed to have unused dependencies.
625 625 .RE
626 626
627 627 .sp
628 628 .ne 2
629 629 .mk
630 630 .na
631 631 \fBUNUSED_OBJ\fR
632 632 .ad
633 633 .RS 17n
634 634 .rt
635 635 .sp
636 636 Objects that are always allowed to be unused dependencies.
637 637 .RE
638 638
639 639 .sp
640 640 .ne 2
641 641 .mk
642 642 .na
643 643 \fBUNUSED_RPATH\fR
644 644 .ad
645 645 .RS 17n
646 646 .rt
647 647 .sp
648 648 Objects that are allowed to have unused runpath directories.
649 649 .RE
650 650
651 651 .LP
652 652 .SH ALTERNATIVE DEPENDENCY MAPPING
653 653 .I check_rtime
654 654 was primarily designed to process a nightly builds \fB$ROOT\fP
655 655 hierarchy. It is often the case that objects within this hierarchy
656 656 must bind to dependencies within the same hierarchy to satisfy
657 657 their requirements.
658 658 .LP
659 659 To achieve this,
660 660 .I check_rtime
661 661 uses the shared objects specified with the \fB-D\fP or \fB-d\fP options.
662 662 If neither option is specified, and the \fB$CODEMGR_WS\fP and \fB$ROOT\fP
663 663 environment variables are defined, the proto area for the workspace
664 664 is used. The objects found are used
665 665 to create runtime configuration files via \fBcrle(1)\fP, that establish
666 666 the new shared objects as alternatives to their underlying system location.
667 667 .I check_rtime
668 668 passes these configuration files as \fBLD_CONFIG\fP environment
669 669 variable settings to \fBldd(1)\fP using its \fB-e\fP option.
670 670 .LP
671 671 The effect of these configuration files is that the execution of an
672 672 object under \fBldd(1)\fP will bind to the dependencies defined as
673 673 alternatives. Simply put, an object inspected in the \fIproto\fP
674 674 area will bind to its dependencies found in the \fIproto\fP area.
675 675 Dependencies that have no alternative mapping will continue to
676 676 bind to the underlying system.
677 677 .LP
678 678 .SH ENVIRONMENT VARIABLES
679 679 .LP
680 680 When the \fB-D\fP or \fB-d\fP option isn't in use,
681 681 .I check_rtime
682 682 uses the following environment variables to
683 683 establish an alternative dependency mapping:
684 684 .LP
685 685 .B CODEMGR_WS
686 686 .RS 4
687 687 The root of your workspace, which is the directory
688 688 containing \fICodemgr_wsdata\fP. Existence of this environment variable
689 689 indicates that \fB$ROOT\fP should be investigated.
690 690 .RE
691 691 .LP
692 692 .B ROOT
693 693 .RS 4
694 694 Root of the \fIproto\fP area of your workspace. Any shared objects
695 695 under this directory will be used to establish an alternative dependency
696 696 mapping.
697 697 .RE
698 698 .sp
699 699 If \fBldd(1)\fP supports the \fB-U\fP option, it will be used to determine
700 700 any unreferenced dependencies. Otherwise \fBldd(1)\fP uses the older
701 701 \fB-u\fP option which only detects unused references. If the following
702 702 environment variable exists, and indicates an earlier release than \fB5.10\fP
703 703 then \fBldd(1)\fP also falls back to using the \fB-u\fP option.
704 704 .RE
705 705 .LP
706 706 .B RELEASE
707 707 .RS 4
708 708 The release version number of the environment being built.
709 709 .RE
710 710 .SH ERROR CONDITIONS
711 711 .LP
712 712 Inspection of an object with \fBldd(1)\fP assumes it is compatible
713 713 with the machine on which
714 714 .I check_rtime
715 715 is being run. Incompatible objects such as a 64-bit object encountered on
716 716 a 32-bit system, or an i386 object encountered on a sparc system,
717 717 can not be fully inspected. These objects are displayed as:
718 718 .sp
719 719 .RS 4
720 720 foo: has wrong class or data encoding
|
↓ open down ↓ |
331 lines elided |
↑ open up ↑ |
721 721 .RE
722 722 .LP
723 723 .SH FILES
724 724 .LP
725 725 .RS 5
726 726 $CODEMGR_WS/exception_list/check_rtime
727 727 /opt/onbld/etc/exception_list/check_rtime
728 728 .SH SEE ALSO
729 729 .B crle(1),
730 730 .B elfdump(1),
731 -.B find_elf(1),
731 +.B find_elf(1ONBLD),
732 732 .B ldd(1),
733 733 .B ld.so.1(1),
734 734 .B mcs(1).
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX