[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:       Dirk Mueller <mueller () kde ! org>
Date:       2001-05-29 22:35:34
[Download RAW message or body]

On Die, 29 Mai 2001, Michael Matz wrote:

> 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? 

Well, I'm not sure what -Bsymbolic does. But at least I'm catching up, I 
just started reading ELF spec and read before various whitepapers on these 
issues, but its near end of the month so my printer quota is already 
exceeded for the last two weeks ;)

I had the impression that -Bsymbolic avoids the symbol lookup when 
possible. 

> I was merely
> talking about making all relocs from a DSO into itself resolve it's
> symbols at link-time.

Ah, seems my guess wasn't that wrong after all :-)

> >  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,

I read the reply and it seems to be designed to work this way. lets see if 
we can deal with it or if we have to reinvent the wheel. 

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

Yes. Still ELF might be a fine invention for C-based applications that need 
to overwrite their symbols in different libs or for debugging purposes as in 
libefence and similiar, but we're doing C++ here which does not make any use 
of this as far as I can see. We should have a way to switch this bloated 
part off. As you found out, this does not work for our favourite ::self() 
access methods to a uniquely instanciated object. I'm not yet sure if this 
is a showstopper or if there is some way to still make it working. 

As Waldo pointed out the current problem is mostly the vtable 
implementation, which we really hit badly with kdeui - reimplementing the 
horrible amount of virtual methods of QWidget for a huge number of classes. 

Luckily there are only 4 additional virtual methods of Qt3's QWidget and 
one less in QObject so the situation isn't getting much worse with Qt 3.
At least I hope so. Eventually half a dozen of virtual methods could be 
removed from QWidget in Qt 3 without too much drawbacks, but I don't think 
this is making any difference after all and as it breaks the SC TT won't be 
happy at all about such a suggestion. 


Dirk

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