Bug 57672 - Undefined variable - fam
Undefined variable - fam
Product: Red Hat Raw Hide
Classification: Retired
Component: fam (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Alexander Larsson
: 57826 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2001-12-18 12:36 EST by Sammy
Modified: 2008-05-01 11:38 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-01-07 15:49:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Sammy 2001-12-18 12:36:05 EST
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:

Actual Results:

Expected Results:

Additional Information:
Comment 1 Alexander Larsson 2001-12-19 01:24:23 EST
Bero. I remember seeing you talk about this somewhere. Did you rebuild fam with
the new compiler?
Comment 2 Bernhard Rosenkraenzer 2001-12-19 03:25:38 EST
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).
Comment 3 Sammy 2001-12-19 15:48:03 EST
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?
Comment 4 Todd Mokros 2001-12-29 21:14:16 EST
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
/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++.
Comment 5 Matt Wilson 2002-01-07 12:11:42 EST
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
Comment 6 Bernhard Rosenkraenzer 2002-01-07 12:16:25 EST
No, it should use -lsupc++ rather than -lstdc++. fam is C++, but doesn't make
use of any STL functions, so supc++ is sufficient.
Comment 7 Alexander Larsson 2002-01-07 14:09:32 EST
Cool. I'll upgrade to 2.6.7 and add -lsupc++ to the linkline.
Comment 8 Alexander Larsson 2002-01-07 15:26:32 EST
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.

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?
Comment 9 Alexander Larsson 2002-01-07 15:49:41 EST
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.
Comment 10 Alexander Larsson 2002-01-07 15:59:37 EST
Ok. This should be fixed in 2.6.7-2.
Comment 11 Alexander Larsson 2002-01-13 14:17:48 EST
*** Bug 57826 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.