While using valgrind to confirm a C++ program had no memory leaks, I noticed that symbols for libstdc++ were not being loaded: --00:00:00:00.373 26460-- Reading syms from /usr/lib64/gcc/x86_64-pc-linux-gnu/4.3.4/libstdc++.so.6.0.10 (0x4e2a000) --00:00:00:00.375 26460-- object doesn't have a symbol table However, symbols do exist and were installed via FEATURES=splitdebug: $ ls -l /usr/lib/debug/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/libstdc++.so.6.0.10.debug -rw-r--r-- 1 root root 355466 2009-10-31 16:41 /usr/lib/debug/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/libstdc++.so.6.0.10.debug The problem was first noticed on a system with gcc:4.4, but is present also on gcc:4.3. I unmasked and installed gcc:4.5 to confirm that it placed files in the same way, but avoided selecting it or using it to build, so as to avoid needless complications in bug reports. After tinkering with moving files around, I isolated the problem to a multilib related path issue. On typical Gentoo systems, /usr/lib is a symlink to lib64, but nothing assures that /usr/lib/debug/usr/lib is a symlink to the corresponding lib64. sys-devel/gcc:4.3, :4.4, and :4.5 all install their files in /usr/lib, not /usr/lib64. The /usr/lib symlink hides this detail for the main files, but no such hiding occurs for split out debug symbols. As a result, when valgrind seeks out /usr/lib/debug/usr/lib64/gcc/x86_64-pc-linux-gnu/4.3.4/libstdc++.so.6.0.10.debug, it finds no match, because the symbols were installed as <.../debug/usr/lib/...>. Manually combining /usr/lib/debug/usr/lib{,64} and adding a lib->lib64 symlink in the debug area works around the problem, but it would be nice to fix it properly by installing to /usr/lib64. Steps to reproduce: echo 'int main() { return 0; }' > truecxx.cpp g++ -O2 -ggdb truecxx.cpp -o truecxx valgrind -v ./truecxx Expected results: Symbol table loaded successfully. Actual results: Symbol table not found. strace confirms that valgrind looks in the wrong place: strace -e trace=open !valgrind Work around: # cd /usr/lib64/debug/usr # tar -C lib -c -f - . | tar -C lib64 -x -f - # rm -rf lib ; ln -s lib64 lib Variations on this workaround are possible, but early testing revealed that there were some colliding directories that caused mv to reject simple attempts, so copying and deleting was easier. I can see two possible solutions for this bug. One solution would be to adjust the library path to be /usr/$(get_libdir) instead of /usr/lib. This requires a fix in each offending package. The other solution would be a Portage hack to ensure that the split out debug area uses the same lib->lib64 symlink as is used in the main area, thereby hiding occurrences of the path mismatch.
emerge --info please
(In reply to comment #1) > emerge --info please Was the information in comment #0 in some way insufficient to pursue the problem? I provided steps to reproduce and the versions of the affected packages. I described the problem, explained why it happens, and offered two possible fixes: fix the ebuilds to use get_libdir or add a hack to force the symbols to alias the same way the main lib/lib64 directories do. I do not see what relevant information could be had from emerge --info, and thus do not understand why this bug was resolved as NEEDINFO.
(In reply to comment #2) > (In reply to comment #1) > > emerge --info please > > Was the information in comment #0 in some way insufficient to pursue the > problem? Nevermind. This problem was subsequently re-reported by Mariusz Ceier on 2010-09-18 15:09 as bug #337951 (sys-devel/gcc on amd64 multilib with splitdebug feature puts debug symbols in /usr/lib/debug/usr/lib/gcc, and dev-util/valgrind-3.5.0 looks for them in /usr/lib/debug/usr/lib64/gcc) and assigned to toolchain@ by dirtyepic@. Although that report contains less detail than comment #0 here, dirtyepic isolated the cause and vapier seems to be considering whether to make the fix.
