I installed sys-libs/glibc-2.33 using the "debugsyms installsources" environment. It works, but some source files are not installed in /usr/src/debug. An example is "pthread_create.c". A user reported the issue in the Gentoo forums: https://forums.gentoo.org/viewtopic-p-8628003.html#8628003 It happens on my machine, too. I'm not a debugging expert, so I don't fully understand what's going on. It seems to me that "pthread_create.c" (and more files) should be installed, but I can be wrong. Reproducible: Always
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!