Red Hat Bugzilla – Bug 57672
Undefined variable - fam
Last modified: 2008-05-01 11:38:01 EDT
Description of Problem:
After updating fam this morning to 2.6.6-2 my KDE logins stopped
working...after investigating I discovered that when KDE was
running kbuildsycoca it was crashing wiht a message coming
from fam that a certain name _Ze.... was missing in some dynamical
library. I do have the gcc-3.1, glibc-2.2.4-20, and all the compatibility
libraries although the message sounds like some binary incompatibility.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Bero. I remember seeing you talk about this somewhere. Did you rebuild fam with
the new compiler?
Yes, I rebuilt it a couple of days ago (the rebuilt version is
Are you still using kde 2.2.x? That won't work. You need to update
to the KDE packages in rawhide at the same time (using a gcc 3.1 lib with
a gcc 2.96 application is a no-go and vice versa).
If you don't feel like updating KDE to a CVS snapshot, you'll need
to recompile the packages from 7.x (or ftp.kde.org).
Yes, I am using kde-2.2.2 that I compiled in current rawhide BUT using
gcc296 and g++296. It seems a little difficult to compile kde-2.2.2 with
gcc-3.1 since first one must compile qt-2.3.x, and there I ran into a
problem if I remember correctly. I may try again. Is qt2-2.3.2-1
compiled with gcc-3.1?
I'm having a similar problem, but this is with regards to nautilus. I have
nautilus-1.0.6-2 and fam-2.6.6-2 installed. When I try to start nautilus gives
the following error:
nautilus: relocation error: /usr/lib/libfam.so.0: undefined symbol:
It appears that this symbol should be found in libstdc++.so.4. `ldd
libc.so.6 => /lib/i686/libc.so.6 (0x4002c000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
no reference to libstdc++ there, and since nautilus is C not C++, libstdc++
doesn't get linked in. /usr/bin/fam doesn't have this problem since it's c++.
Either the c++ code in libfam shouldn't be there, or libfam.so.0 needs to be
linked with libstdc++.
This is probably due to libtool not using g++ to link. If it uses gcc to link
it won't get the requirement. We could also add -lstdc++ to the link line for
No, it should use -lsupc++ rather than -lstdc++. fam is C++, but doesn't make
use of any STL functions, so supc++ is sufficient.
Cool. I'll upgrade to 2.6.7 and add -lsupc++ to the linkline.
I added -lsupc++ to libfam_la_LIBADD, in the hope of fixing this, but libtool does:
/bin/sh ../libtool --mode=link g++ -O2 -march=i386 -mcpu=i686 -o libfam.la
-rpath /usr/lib -export-symbols fam.sym Cl
ient.lo fam.lo -lsupc++
rm -fr .libs/libfam.la .libs/libfam.* .libs/libfam.*
*** Warning: This library needs some functionality provided by -lsupc++.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
gcc -shared Client.lo fam.lo -Wl,-soname -Wl,libfam.so.0
-Wl,-retain-symbols-file -Wl,fam.sym -o .libs/libfam.so.0.0.
So it drops the -lsupc++ from the final linkline!
Perhaps this is because libtool couldn't find
/usr/lib/gcc-lib/i386-redhat-linux/3.1/libsupc++.a or something.
I think we need to link to libstdc++ here anyway. Linking the library statically
may cause problems if the app that links to fam is linked to libstdc++. Then we
get all sorts of weird collisions.
And libsupc++.a is probably not PIC code anyway.
Ok. This should be fixed in 2.6.7-2.
*** Bug 57826 has been marked as a duplicate of this bug. ***