[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 23:06:16
[Download RAW message or body]

Hi,

On Wed, 30 May 2001, Dirk Mueller wrote:
> I had the impression that -Bsymbolic avoids the symbol lookup when
> possible.

Yup.  (Even when not possible, as we learned now ;-) )

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

Well, when we really wanted to use -Bsymbolic in it's current form we have
to compile everything -fPIC.  I hope the binutils people hack something,
so -Bsymbolic only touches functions.

On another front, I think somewhen we'll have better compiler support for
various ELF features.

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

Exactly.  Nobody in his right mind would want to override mangled C++
symbols.

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

The point is, that either the data must not be shared (so all inline
accessors to it need to go outline; bad), or the app needs to be PIC, or
-Bsymbolic needs to become more intelligent.  Or to not use -Bsymbolic at
all.  If nothing of the above is fulfillable, it's a showstopper.  (Btw.
kapp is such a thing, so virtually nothing would work in KDE, right now
with -Bsymbolic libraries).

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

Yep, and there was some discussion about this on the various lists.  Let's
give it some time (or implement something ourself, I still think
prelinking all libs on disk is the most profitable way).


Ciao,
Michael.

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