>>>>> "Ken" == Ken Raeburn via RT <rt-comment@krbdev.mit.edu> writes:

    Ken> On Dec 28, 2005, at 18:16, Sam Hartman via RT wrote:
    >> My personal opinion is that if we can do this in a manner where
    >> we guarantee that the symbol visibility and export lists do not
    >> conflict then we should do so.

    Ken> There are two main types of conflict there.

    Ken> First, a symbol marked hidden/internal but in the export
    Ken> list.  From a test I did a little while ago, it appears that
    Ken> it wouldn't show up in the dynamic symbol table.  I was
    Ken> thinking of adding a test program that would walk through the
    Ken> export list and try calling dlsym on each symbol.

    Ken> Second, a symbol with default visibility but not in the
    Ken> export list.  This would be okay, it's just likely to be less
    Ken> efficient.  Though for platforms where visibility is
    Ken> supported but export lists are not (are there any?), it might
    Ken> be desirable to run nm and examine the output for
    Ken> unrecognized, defined symbols.

O, sorry, I meant to imply that we should set things up so all our
symbol properties come from one place.  I.E. it is impossible to get
it wrong because there is only one place the data lives so it cannot
be inconsistent with anything.

--Sam