Summary: | sys-libs/glibc-2.33: missing source files in debugsyms installsources environment | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Michael Hofmann <bugs> |
Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | gentoo |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=622196 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 799260 | ||
Bug Blocks: | 933986 | ||
Attachments: |
emerge --info
build.log.gz List of files in /usr/src/debug/sys-libs/glibc-2.33/glibc-2.33/nptl Build log |
Description
Michael Hofmann
2021-06-28 11:48:56 UTC
I think it's a limitation of debugedit: bug #768444. gcc-11 generates dwarf-5 that debugedit does not parse. As a wourkaround you can try to add -gdwarf-4 into CFLAGS. I'm on stable and I use GCC 10. debugedit is NOT installed on my machine. Some source file like "pthread_self.c" get installed in /usr/src/debug, others like "pthread_create.c" do NOT get installed. Ah, thanks for the details. The fact that pthread_self.c is being installed for you is surprising to me. FEATURES=installsources requires debugedit: https://github.com/gentoo/portage/blob/master/bin/estrip#L168 In you share `emerge --info` and glibc's build.log maybe it will shed sole light. Created attachment 719874 [details]
emerge --info
Created attachment 719877 [details]
build.log.gz
Thanks for looking into this! I installed "dev-util/debugedit" on my machine, ran FEATURES="keepwork" emerge --oneshot glibc and uploaded the build log as well as the output of "emerge --info". I'll also upload a list of the files that are installed in "/usr/src/debug/sys-libs/glibc-2.33/glibc-2.33/nptl" Created attachment 719880 [details]
List of files in /usr/src/debug/sys-libs/glibc-2.33/glibc-2.33/nptl
(In reply to Michael Hofmann from comment #5) > Created attachment 719877 [details] > build.log.gz Due to FEATURES=keepwork it's not cleat how (and if at all) pthread_create.c was compiled on your system. My guess is that a debugging flag was missing from CFLAGS on your system. Usually you want at least -g1 in CFLAGS to get some debugging references to source code. Created attachment 719940 [details]
Build log
This is the full build log
Sergei, I'm sorry! I uploaded the wrong build log file. The compile phase was missing. Please accept my apologies. I just uploaded the correct build log. Line 1880 shows that "pthread_create.c" was compiled and that option "-ggdb" was used. (In reply to Michael Hofmann from comment #9) > Created attachment 719940 [details] > Build log > > This is the full build log I think I reproduced the effect you are seeing. Here is my attempt (with debugedit installed): 1. FEATURES=installsources LANG="en_US.utf8" LINGUAS="de en" CFLAGS="-march=native -O2 -pipe" CXXFLAGS="-march=native -O2 -pipe" emerge -v1 glibc result: no sources installed 2. FEATURES=installsources LANG="en_US.utf8" LINGUAS="de en" CFLAGS="-march=native -O2 -pipe -ggdb" CXXFLAGS="-march=native -O2 -pipe -ggdb" emerge -v1 glibc result: has sources installed, but not the pthread_create.c It's an unintended side-effect of 'dostrip -x $(alt_libdir)/libpthread-${upstream_pv}.so' in glibc's ebuild. It tries to prevent debugging stripping but might have a side-effect of skipping installsources. Verified with: --- a/sys-libs/glibc/glibc-2.33.ebuild +++ b/sys-libs/glibc/glibc-2.33.ebuild @@ -1216,7 +1216,7 @@ glibc_do_src_install() { is_crosscompile && dostrip -x / # gdb thread introspection relies on local libpthreas symbols. stripping breaks it # See Note [Disable automatic stripping] - dostrip -x $(alt_libdir)/libpthread-${upstream_pv}.so + #dostrip -x $(alt_libdir)/libpthread-${upstream_pv}.so if [[ -e ${ED}/$(alt_usrlibdir)/libm-${upstream_pv}.a ]] ; then # Move versioned .a file out of libdir to evade portage QA checks I think it's a portage's bin/estrip bug. I'll craft a shorter reproducer this evening and file a bug against portage. Looks like there is no nice workaround to make it work today. Filed bug #799260 Sergei, thanks for looking into this and for creating bug #799260 with a test case! |