2008/148: new ldd(1) -p option

[Rod Evans]

James Carlson wrote:
>
> (I'd suggest reverse logic, if anything: a way to restore the bogus
> errors for those who simply must see them.  But I doubt that's really
> required, and there are probably better ways to do it.)

Sorry to take so long getting back ... fire drills else where.

With your comments and others, I've indeed reversed the logic.
ldd(1) will silence any unresolved PARENT or EXTERN errors when
inspecting a shared object by default.  Note, when inspecting
an executable, which should have all relocations resolved for
the process, *any* unresolved errors will still be displayed,
just as they always have been, no matter whether PARENT or
EXTERN directives have been used or not in any component of the
process.

But we're, still going to have a -p, and this will be used to
expose any unresolved PARENT or EXTERN errors.  The -p is now in
keeping with the -w, which can be used to expose unresolved weak
resolutions.

------------------------------------------------------------------------

Man page diffs:

 >      ldd [-d | -r] [-c] [-e envar] [-f] [-i] [-L] [-l] [-p] [-s]
 >
 >      ....
 >
>      Some  unresolved  symbol  references  are  not  reported  by
>      default.  These  unresolved  references can be reported with
>      the following options. These options can  be  combined  with
>      either the -d option or the -r option.
> 
>      -p  Expose any unresolved symbol errors to  explicit  parent
>          and external references.
> 
>      -w  Expose any unresolved weak symbol references.
> 
>      A shared object can make reference to symbols that should be
>      supplied  by  the  caller of the shared object. These refer-
>      ences can be explicitly classified when the shared object is
>      created,  as  being  available  from  a parent, or simply as
>      being external. See the -M mapfile option of ld(1), and  the
>      PARENT and EXTERN symbol definition keywords. When examining
>      a dynamic executable, a parent or  external  reference  that
>      can  not  be  resolved  is  flagged  as an error. However by
>      default, when examining a shared object, a parent or  exter-
>      nal  reference that can not be resolved is not flagged as an
>      error. The -p option, when used with either  the  -d  or  -r
>      options,  causes any unresolved parent or external reference
>      to be flagged as a relocation error.

------------------------------------------------------------------------

Release Binding:               Patch/Micro
ldd -p option                  Committed

-- 
Rod