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): How Reproducible: Steps to Reproduce: 1. 2. 3. Actual Results: Expected Results: Additional Information:
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 2.6.6-2) 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: _ZTVN10__cxxabiv117__class_type_infoE It appears that this symbol should be found in libstdc++.so.4. `ldd /usr/lib/libfam.so.0` shows: 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 libfam.
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.
F**King libtool. 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. 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. Any ideas?
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. ***