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

[James Carlson]

Rod Evans writes:
> James Carlson wrote:
> > If the symbols have been explicitly classed such that they're supposed
> > to be resolved by the parent, then why should ldd complain about them
> > in the first place?
> > 
> > Why is "-p" needed, rather than just making that behavior the default?
> > Isn't the "EXTERN" tag enough information?
> 
> You're not the first to make this observation :-)

The first version of that message I drafted started with "this may be
a dumb question, but ..." -- so it's good to hear I at least have
company.  ;-}

> Yes, the new ldd(1) functionality could be implemented as
> the default behavior, and thus error messages that used to
> occur would magically disappear.  As usual, I was concerned
> that any change in existing behavior might be noticed, and
> perhaps unappreciated by one or two.

The change in behavior, though, is accompanied by a change in the
source code of the application.  In other words, ldd(1) would still do
exactly the same thing on the same set of traditional bits.  It would
just gain new functionality (not complaining as much) when the
application writer uses the 'EXTERN' or 'PARENT' symbol, something I
doubt is very common, and is in any event quite intentional.

> And thus I also had the fear that someone might ask for a
> new option (-p :-) to re-expose the symbols that aren't
> explicitly defined by their present dependencies, but were
> expected to be found somewhere from the objects callers.
> 
> Hence my direction - but I could be easily swayed.

The new functionality seems completely in keeping with the original
intent of those mapfile keywords, so I don't see a reason to be
concerned about the change.

(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.)

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677