Bug 97543

breaks digikam and a few other KDE packages.  
 
 

ok, I suck.. the error message is: 
 
/usr/lib64/gcc/x86_64-suse-linux/4.0.2/../../../../x86_64-suse-linux/bin/ld: /tmp/ccY9bnzi.o: 
relocation R_X86_64_32 against `QString::null' can not be used when making a 
shared object; recompile with -fPIC 

Hmm, wasn't visibility switched off for such reasons in KDE on x86-64? 
OTOH we have some additional patches on top (from HJ Lu), which were supposed 
to make this visibility stuff work on more platforms than x86, and perhaps 
that breaks other things, or is not complete enough. 

not upstream.. can't find such a change in the suse packages, but could be 
that I'm missing something. strangely it works for most packages though.  

Hmm, it might that it was implicitely switched off in the past by the normal 
autoconf check testing for visibility support, which once determined that 
on x86-64 it indeed did not work.  Then we added the patch on our GCC, and 
it started to basically work (including the autoconf test), but it seems now 
not completely :(  I can reproduce it now (next time, please also attach 
a preprocessed file, accelerates the process a bit).  I'm looking at it. 

I've reduced it to this code: 
---------------------------------- 
struct A { 
  virtual bool operator== (const A &a) const; 
  virtual bool operator!= (const A &a) const; 
}; 
inline bool A::operator!= ( const A &a) const 
{ return !(*this == a); } 
void breakme(const A& newPath, A &b) 
{ 
  A(newPath) != b; 
} 
----------------------------------- 
 
The problem is, that no out-of-line copy of operator != is generated for 
this shared object.  This is so, because out-of-line copies are only generated 
in the object which contains the implementation of the key method (normally 
the first virtual function of the class).  So there's no implementation 
of operator!= in this DSO, which could be made hidden. 
 
In the case at hand GCC fails to inline this very call for whatever reasons. 
So the remaining call is generated _as if_ there is a local hidden 
implementation (because of the flag), which means a call not going over PLT. 
Such calls are not allowed in shared libs if they call to either undefined 
or non-local symbols. 
 
I don't know why this doesn't happen for CVS 4.0.  Perhaps there the call is 
inlined. 

It's not inlined because it is known too late which function actually is 
called.  It's a virtual function, so very early the called function is loaded 
over the vtable.  If the body of breakme is "newPath != b" (no copying of A), 
then there is no error, because the call over the vtable doesn't access 
a symbol.  But with the copy in there, the compiler can determine that the 
type of the object on which to call operator!= really is "A", and then 
can optimize the virtual call to a direct function call.  But at that 
time it's already too late for inlining.  So an uninlined call will remain, 
with the observed effects. 

Perhaps Honza has an idea. 

Ah, it's not just our compiler.  Exactly the same happen also in CVS 4.0. 

sorry. ok, filing bugreport upstream then. or did you already? 

I will do. 

Although I forgot to mention it here, I filed this as 
  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22592 

was resolved as invalid upstream.