[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: exporting symbols (was Re: The goodness of goodness)
From:       Michael Matz <matz () kde ! org>
Date:       2001-05-29 21:22:24
[Download RAW message or body]

Hi,

On Tue, 29 May 2001, Dirk Mueller wrote:
>
> > libkhtml.so.3.0.0 : 16583 - 2368

I swapped your sentences a little:

> Wow. That sounds like it makes a difference. Except
> that the private method symbol is no longer exported (i.e. the #define
> private public hack is broken :-] )

Huh?  You don't confuse this with the yet to be written C++ analyzer and
it's appklication for generating export-lists, don't you?  I was merely
talking about making all relocs from a DSO into itself resolve it's
symbols at link-time.

>  What are the drawbacks

Well, apart from not working? ;-)  Given that a bug (see gcc@ if you are
interested) is fixed (may be it already is, I only noticed it today) in
either ld.so, ld, as, gcc or whereever, the only drawback would be that
the following example wouldn't work: Consider a lib1.cpp:
void m() {doit();}
void n() {m(); m();}

Now ELF semantics specify, that for a program it is possible to provide a
m() itself, which then gets used by the libraries calls in n() (so
lib1's m() is basically unused).  Likewise for any m() in any DSO which
is before lib1 in symbol search order (which is quite convoluted).
Basically ELF allows overriding of symbols even _intra-library-wise_ (as
above) which, yes, is a "interesting" feature.  m() must be externally
visible, then any correct ELF implementation must provide means for this
possibility.  But it may also provide means to switch off this behaviour
for symbols defined in the same DSO, although they are externally visible.

When now n()'s call to m() is resolved at linktime, there is no possiblity
to override it anymore.  Note that this _only_ applies to the call-sites
in lib1 itself.  Any other DSO originally also using lib1's m() could
still be overrode to use e.g. the programs m().

So this all complements the wannabe hiding of complete internal classes or
methods (K_EXPORT) (That hiding also result in resolving the symbols at
link time, as now there is anyway no way to override the symbols from
anywere else.  This time it then also applies to other DSO's not just
the one defining the symbols.).


Ciao,
Michael.

[prev in list] [next in list] [prev in thread] [next in thread]