[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-30 0:35:07
[Download RAW message or body]

On Mit, 30 Mai 2001, Michael Matz wrote:

> Well, when we really wanted to use -Bsymbolic in it's current form we have
> to compile everything -fPIC. 

That is not a big drawback, is it ? 

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

Yeah, a weak and versioned symbol support would be a great thing to have to 
maintain BC in C++ based libraries. Any known plans in that direction ?

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

As far as I understood, it can't be made more intelligent. what I'm thinking 
of is telling the init() method in the lib not to use its own copy of the 
global object pointer but the one in the dynamic BSS section of the 
application. This way both would be happy and still be optimized for the 
common case.  

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

I read in a few places about a magic new implementation of ld by Uli. didn't 
find anything concrete on it though. Do you know something about that?

Related I found 

http://msdn.microsoft.com/msdnmag/issues/0500/hood/hood0500.asp

pretty interesting to read. The ideas given there (assigning a perferred 
BASE address, saving all the finished relocations in the actual executable) 
are worth thinking about. 


Dirk

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