Bugzilla – Bug 97543
compile error involving -fvisibility
Last modified: 2006-10-05 11:01:45 UTC
appears to be suse specific. testcase: === Cut === #include <qdir.h> void breakme(const QString& newPath) { QDir(newPath) != QDir(QDir::homeDirPath ()); } === Cut === g++ -v -fPIC -DPIC -I/usr/lib/qt3/include -fvisibility=hidden -fvisibility-inlines-hidden -Wall -O2 -o libtest.so -shared testcase.cpp ... GNU C++ version 4.0.2 20050714 (prerelease) (SUSE Linux) (x86_64-suse-linux) ... removing -fvisibility-inlines-hidden fixes it.
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.