Summary: | sys-libs/pam points ${WORKDIR} as debug-prefix-map | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Necktwi Ozfguah <necktwi> |
Component: | Current packages | Assignee: | Portage team <dev-portage> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | base-system, pam-bugs+disabled, sam, zlogene |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
pam-1.3.1-r1-db.tar.gz
pam-info |
Description
Necktwi Ozfguah
2018-12-08 14:51:47 UTC
- 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 |