I expect FEATURES="installsources" CFLAGS="-ggdb" emerge sys-libs/pam debug symbols point the sources at /usr/src/debug/ but instead they point to /tmp/portage/.../work/...: (gdb) s pam_authenticate (pamh=0x5555634520, flags=0) at /tmp/portage/sys-libs/pam-1.3.1-r2/work/linux-pam-1.3.1/libpam/pam_auth.c:20 20 /tmp/portage/sys-libs/pam-1.3.1-r2/work/linux-pam-1.3.1/libpam/pam_auth.c: No such file or directory.
- What pam version? - What do you try to debug and how? - what use flags were set compiling pam? These are all unclear
Created attachment 557490 [details] pam-1.3.1-r1-db.tar.gz emerge flags
Version: pam-1.3.1-r1 I tried to debug with gdb from emacs with "gud" extension. From my C++ program, I'm calling pam_authenticate(). Everything is fine if I ebuild /usr/portage/sys-libs/pam/pam-1.3.1-r2.ebuild prepare and debug. Please find the /var/db/pkg/sys-libs/pam-1.3.1-r2/ attached, for the use flags. Don't mind "r2" its just "r1" with a custom indentation for my convenience.
(In reply to Necktwi Ozfguah from comment #3) > Version: pam-1.3.1-r1 > > I tried to debug with gdb from emacs with "gud" extension. > From my C++ program, I'm calling pam_authenticate(). > Everything is fine if I ebuild /usr/portage/sys-libs/pam/pam-1.3.1-r2.ebuild > prepare and debug. > > Please find the /var/db/pkg/sys-libs/pam-1.3.1-r2/ attached, for the use > flags. > Don't mind "r2" its just "r1" with a custom indentation for my convenience. Well your attachment is merely useless, `emerge --info =sys-libs/pam-$(version)` output is your friend.
Created attachment 557498 [details] pam-info emerge --info =sys-libs/pam-1.3.1-r2
I re-read the initial description, you should use both installsources and splitdebug FEATURES, so gdb can use splitted debug info in /usr/lib/debug.
but glibc with same env(/etc/portage/package.env) got its debug symbols pointing at right location: sys-libs/pam suppress_distcc debugsyms installsources sys-libs/glibc suppress_distcc debugsyms installsources
RPi3B:~ Necktwi$ cat /etc/portage/env/debugsyms CFLAGS="${CFLAGS} -ggdb" CXXFLAGS="${CXXFLAGS} -ggdb" FEATURES="${FEATURES} splitdebug compressdebug -nostrip" #USE="debug"
(In reply to Mikle Kolyada from comment #6) > I re-read the initial description, you should use both installsources and > splitdebug FEATURES, so gdb can use splitted debug info in /usr/lib/debug. how is this relevant? The env remembers the initial debug symbols dir, thats why it was ok for you if you run src_prepare stuff, because otherwise workdir is removed if merge went succesfully. But I do not see the point to change pam behaviour about it, people can still use splitdebug, as it is generec proper way of doing this.
what is the pam behavior? I already used splitdebug for pam. after proper merge, pam is looking for symbols in workdir.
(In reply to Necktwi Ozfguah from comment #10) > what is the pam behavior? I already used splitdebug for pam. after proper > merge, pam is looking for symbols in workdir. I have no idea what is wrong with your installation then, I have just checked everything myself and it reads debug symbols from /usr/lib/debug, so this is exectly pam irrelevant
I'm not saying that /usr/lib/debug/ don't have debug symbols, but the debug symbols present there are pointing to the sources in workdir instead of pointing them in /usr/src/debug/
You had better provide all the info initially
I think I do not want to change CFLAGS directly, this is not common, maybe the portage team want to implement something generic about debug paths
Surely fixed by: commit eb07a754c3ef70e7165adb2e0800050d95dc10ee Author: Sam James <sam@gentoo.org> Date: Wed Jan 8 04:15:54 2025 +0000 sys-libs/pam: add 1.7.0_p20241230 * Switch to Meson * Wire up elogind+logind support (bug #931115) as it's now available upstream * Docs are hard-disabled for now, but that's sort of fine (enough) for now given that we had bug #913087 for the previous ebuild * Using a snapshot as there's a few build system patches post-tag and some other generally noteworthy patches we'd have to pull in manually otherwise * Wire up verify-sig for the next release (but not used for this ebuild as took a snapshot) Bug: https://bugs.gentoo.org/913087 Bug: https://bugs.gentoo.org/942075 Closes: https://bugs.gentoo.org/929970 Closes: https://bugs.gentoo.org/925334 Closes: https://bugs.gentoo.org/931115 Signed-off-by: Sam James <sam@gentoo.org> And if it isn't, it's the same as bug 943185, where there's more detail.
