Using: CFLAGS="${CFLAGS} -ggdb" FEATURES="${FEATURES} splitdebug compressdebug installsources" in package.env break glibc debug symbols, gdb reports trying to debug a program linked against libm: warning: the debug information found in "/usr/lib64/debug//lib64/libm-2.20.so.debug" does not match "/lib64/libm.so.6" (CRC mismatch). This can be worked around by removing the "FEATURE=installsources". Another "fix" is to execute on a x86_64 system: for x in /usr/lib64/debug/lib64/*.debug ; do y=${x#/usr/lib64/debug} y=${y%.debug} objcopy -R .gnu_debuglink --add-gnu-debuglink="${x}" "${y}" done This problem is also described here: https://forums.gentoo.org/viewtopic-t-961866-view-next.html?sid=a4f8b6667b34d30dc1d6689a9917582f so I am pretty sure it's there since long. Reproducible: Always Steps to Reproduce: 1. Compile glibc with CFLAGS="${CFLAGS} -ggdb" FEATURES="${FEATURES} splitdebug compressdebug installsources" 2. Write test program: $ cat test.c #include <stdio.h> #include <math.h> int main() { volatile double foo = 7; printf("%lf", sin(foo)); return 0; } 3. Compile with gcc test.c -ggdb -lm 4. Debug with: gdb ./a.out (gdb) break sin (gdb) r Actual Results: warning: the debug information found in "/usr/lib64/debug//lib64/libm-2.20.so.debug" does not match "/lib64/libm.so.6" (CRC mismatch).
Is there any difference when FEATURES=compressdebug is not used?
(In reply to David Kredba from comment #1) > Is there any difference when FEATURES=compressdebug is not used? Indeed, also with: CFLAGS="${CFLAGS} -ggdb" FEATURES="${FEATURES} splitdebug installsources" the problem vanishes, i.e. even with "installsources", but without "compressdebug", it works.
This is probably some generic problem with portage's compressdebug FEATURE. But cc-ing glibc maintainers just in case.
how exactly did you build gdb ? if you built it w/USE=-zlib, it doesn't support compressed sections.
(In reply to SpanKY from comment #4) > how exactly did you build gdb ? if you built it w/USE=-zlib, it doesn't > support compressed sections. It's build with: client expat lzma nls python server zlib So zlib for sure is there. Furthermore, I am also building other packages, e.g. dev-db/sqlite with: CFLAGS="${CFLAGS} -ggdb" FEATURES="${FEATURES} splitdebug compressdebug installsources" On these, gdb works fine. Up to now, I only got the problem described here with sys-libs/glibc.
Please reopen if this is still the case with non-masked glibc.