Bug 111687
| Summary: | libfam is linked to libstdc++ | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | dann |
| Component: | fam | Assignee: | Alexander Larsson <alexl> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 1 | CC: | jakub |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-02-04 15:15:57 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
-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. 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? 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> 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. 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 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. 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. 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. Jakub, can you comment on the question in the last two comments? 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.
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. |
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: