From kde-core-devel  Wed May 30 00:55:32 2001
From: Waldo Bastian <bastian () kde ! org>
Date: Wed, 30 May 2001 00:55:32 +0000
To: kde-core-devel
Subject: Re: exporting symbols (was Re: The goodness of goodness)
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=99118457819438

On Tuesday 29 May 2001 13:13, Michael Matz wrote:
> Hi,
>
> On Tue, 29 May 2001, Waldo Bastian wrote:
> > If they are non-virtual they currently result in a R_386_JUMP_SLOT
> > relocation
>
> Nope.  E.g. in this example class:
> class A {public:  A();
> private: void m();
> };
> A::A() { m(); m(); }
>
> Here the two calls to m() result in two R_386_PC32 rels which are
> symbol-based, whereas if A::m() would be non-visible, that could be
> converted to _one_ R_386_RELATIVE which is constant-based.  This is also
> what -Bsymbolic is basically doing, but I just noticed a bug in that,
> dealing with static class members returned by inline functions.  If that
> would be fixed we could get to these numbers:

Euhm.. why does my "objdump -R <qt_or_kde_lib>" not show any R_386_PC32 reloc 
at all? Could it be that R_386_PC32 rels are only generated for non-PIC code?

> libkio.so.3.0.0 : 2346 - 1177
> libksycoca.so.3.0.0 : 2090 - 1014
> libkdecore.so.3.0.0 : 3902 - 1920
> libkdesu.so.1.0.0 : 228 - 145
> libkdeui.so.3.0.0 : 20059 - 14226
> libkfile.so.3.0.0 : 4886 - 3621
> libkjava.so.1.0.0 : 618 - 617
> libkhtml.so.3.0.0 : 16583 - 2368
>
> The numbers are symbol-based relocations (lazy and non-lazy)
> (objdump -R .so | grep -v '\*ABS\*' | wc -l), first number normal build
> (not quite current CVS), second number custom build with invoking the
> linker by hand and some options.

Can you do a "grep 'R_386_32' | wc -l" for and after and a "grep 
'R_386_JUMP_SLOT' | wc -l" for and after?

Cheers,
Waldo
-- 
bastian@kde.org | SuSE Labs KDE Developer | bastian@suse.com