Bug 111687 - libfam is linked to libstdc++
libfam is linked to libstdc++
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: fam (Show other bugs)
1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Alexander Larsson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-12-08 14:37 EST by dann
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-02-04 10:15:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description dann 2003-12-08 14:37:40 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007

Description of problem:
libfam is linked to libstdc++, as shown by ldd:

ldd /usr/lib/libfam.so.0.0.0
        libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4a48d000)
        libm.so.6 => /lib/i686/libm.so.6 (0x43971000)
        libc.so.6 => /lib/i686/libc.so.6 (0x4358b000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4a483000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

this is not good because gnome-vfs links to libfam, and in turn all
the packages that use gnome-vfs will have a few pages mapped.
Example from pmap PID_OF_GNOME-PANEL:

40256000      704K r-xp /usr/lib/libstdc++.so.5.0.5
40306000       20K rw-p /usr/lib/libstdc++.so.5.0.5

and this adds up when using a lot of GNOME applications. 

When compiling fam, the command that creates libfam is:

gcc -shared  Client.lo fam.lo  -lstdc++  -Wl,-soname -Wl,libfam.so.0
-Wl,-retain-symbols-file -Wl,fam.sym -o .libs/libfam.so.0.0.0

This patch fixes this:

--- libfam/Makefile.am.orig    2003-12-08 11:30:50.000000000 -0800
+++ libfam/Makefile.am 2003-12-08 11:30:29.000000000 -0800
@@ -8,7 +8,6 @@ libfam_la_SOURCES = \
   fam.c++
 
 libfam_la_LDFLAGS = -export-symbols fam.sym
-libfam_la_LIBADD = -lstdc++
 
 EXTRA_DIST = fam.sym
 


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.ldd /usr/lib/libfam.so.0.0.0
2.
3.
    

Actual Results:  libfam links libstdc++

Expected Results:  libfam does not need to be linked to libstdc++

Additional info:
Comment 1 Alexander Larsson 2003-12-15 11:26:50 EST
-lstdc++ was added because not having it was causing some issue.
Unfortunately i don't remember why. I think it used some c++ thing
that required library support. First it used -lsupc++, but i had to
change that to -lstdc++ since there was some problem with c++ apps
linking to libstdc++ and fam.
Comment 2 dann 2003-12-16 19:14:29 EST
That sounds like either a library bug, or a gcc/binutils toolchain bug.. 

Can the -libstdc++ be eliminated at some point to find out what the
problem is? 
Comment 3 Alexander Larsson 2003-12-17 05:49:54 EST
I'm not gonna build a package in the system that is know to be broken,
but you could build one locally if you want to figure out why -lstdc++
or -lsupc++ was needed. I think linking to both libstdc++ and
libsupc++ in the same app isn't allowed, so thats why we went to
libstdc++.

However, I think the initial problem was with KDE or some other C++
app, so make sure you test these. One could also look through bugzilla
to see what caused this change:
* Mon Jan  7 2002 Alex Larsson <alexl@redhat.com> 2.6.7-1
- Updated to 2.7.6
- removed patches that went in upstream
- added -lsupc++ to the link line for libfam.

I think someone else (bero?) told me this was needed, so thats why my
memory is hazy.
Comment 4 Alexander Larsson 2003-12-17 05:52:25 EST
bug 57672 seems to be the cause of the change.
Comment 5 dann 2003-12-17 12:29:50 EST
OK, I think I found the problem, I could reproduce it with nautilus 
one Fedora Core 1 if -lstdc++ was not used when linking libfam:

(nautilus:17564): libgnomevfs-WARNING **: Cannot load module
`/usr/lib/gnome-vfs-2.0/modules/libfile.so' (/usr/lib/libfam.so.0:
undefined symbol: _ZTVN10__cxxabiv117__class_type_infoE)

The solution is to compile libfam with -fno-rtti.
I don't have KDE installed, I'll install it and try to see if it works. 

Here is a patch:

--- Makefile.am~        2003-12-17 09:22:29.000000000 -0800
+++ Makefile.am 2003-12-17 09:25:09.000000000 -0800
@@ -8,8 +8,9 @@ libfam_la_SOURCES = \
   fam.c++
 
 libfam_la_LDFLAGS = -export-symbols fam.sym
-libfam_la_LIBADD = -lstdc++
+libfam_la_LIBADD = 
 
+AM_CXXFLAGS = -fno-rtti
 EXTRA_DIST = fam.sym
 
 CLEANFILES += ii_files/*.ii
Comment 6 dann 2003-12-18 12:52:38 EST
I spoke too soon...

When using nautilus with a libfam patched as above there is an 
error in nautilus about loading __gxx_personality_v0

It can be solved by either compiling libfam with -fno-exceptions
or by linking to -lsupc++
libsupc++ is compiled with -fPIC, so it should not pose problems. 
Comment 7 Alexander Larsson 2003-12-19 09:54:47 EST
Is linking statically to libsup++ in a library compatible with an app
using the library and linking to libstdc++?

And wouldn't -fno-exceptions make passing exceptions through libfam
impossible for c++ apps? That could break things.
Comment 8 dann 2003-12-19 11:20:40 EST
Can you please ask one of the binutils/g++ maintainers the questions
about libsup++ and -fno-exceptions? 
That person could give an answer that is 100% correct. 
Probably adding such a person to the CC list of this bug should be
enough. Thx.
Comment 9 Alexander Larsson 2003-12-19 12:19:25 EST
Jakub, can you comment on the question in the last two comments?
Comment 10 Alexander Larsson 2003-12-19 12:46:58 EST
I talked to jakub, and we decided that -fno-exceptions -fno-rtti
should be safe, since the C++ use isn't exported (thus you can't use
rtti on it) and there are no callbacks (thus you can't throw
exceptions through it) and it fam itself uses neither rtti nor exceptions.

Additionally, it would be good to add a linker script that hides all
non-public symbols. Something like:
echo '{ global: FAM*; local: *; }' > libfam.map
CFLAGS += -Wl,--version-script,libfam.map
should do it.

Anyway. I'm leaving for xmas now, so I won't be doing this
immediately, but it would surely be a good thing.
Comment 11 Alexander Larsson 2004-02-04 10:15:57 EST
Hmmm. Apparently that didn't work either, since there was a reference
to operator new & delete. So, i made it link to libsupc++ in fam-2.6.10-1.

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