I don't know who is to blame here for the problem? Maybe glibc-2.16 or gcc-4.7.1 or both? Anyway.... trying to recompile sys-lib/pam-1.1.5 with glibc-2.16 and gcc-4.7.1 results in a failure: ----------------------- pam_unix_acct.c: In function '_unix_run_verify_binary': pam_unix_acct.c:97:19: error: storage size of 'rlim' isn't known pam_unix_acct.c:106:5: warning: implicit declaration of function 'getrlimit' [-Wimplicit-function-declaration] pam_unix_acct.c:106:19: error: 'RLIMIT_NOFILE' undeclared (first use in this function) pam_unix_acct.c:106:19: note: each undeclared identifier is reported only once for each function it appears in pam_unix_acct.c:97:19: warning: unused variable 'rlim' [-Wunused-variable] make[3]: *** [pam_unix_acct.lo] Error 1 make[3]: *** Waiting for unfinished jobs.... Analyzing loop at bigcrypt.c:126 make[3]: Leaving directory `/var/tmp/portage/sys-libs/pam-1.1.5/work/Linux-PAM-1.1.5/modules/pam_unix' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/sys-libs/pam-1.1.5/work/Linux-PAM-1.1.5/modules' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/sys-libs/pam-1.1.5/work/Linux-PAM-1.1.5' make: *** [all] Error 2 * ERROR: sys-libs/pam-1.1.5 failed (compile phase): * emake failed * * If you need support, post the output of `emerge --info '=sys-libs/pam-1.1.5'`, * the complete build log and the output of `emerge -pqv '=sys-libs/pam-1.1.5'`. * The complete build log is located at '/var/tmp/portage/sys-libs/pam-1.1.5/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-libs/pam-1.1.5/temp/environment'. * Working directory: '/var/tmp/portage/sys-libs/pam-1.1.5/work/Linux-PAM-1.1.5' * S: '/var/tmp/portage/sys-libs/pam-1.1.5/work/Linux-PAM-1.1.5' >>> Failed to emerge sys-libs/pam-1.1.5, Log file: ----------------------- The solution (I will attach a patch afterwards) for the problem is to add "#include <sys/resource.h>" to modules/pam_unix/pam_unix_acct.c. Reproducible: Always
Created attachment 317302 [details, diff] pam-1.1.5-pam_unix_acct.patch
Most definitely glibc (as I know it works fine with gcc 4.7). Did you send the patch upstream?
Fixed in tree, thanks for the patch — please send it upstream though.
(In reply to comment #2) > Most definitely glibc (as I know it works fine with gcc 4.7). > > Did you send the patch upstream? > No. I have not sent it upstream. I was thinking about sending it upstream but then thought "The maintainer at Gentoo has probably a direct connection upstream. Me sending it upstream would mean registering upstream with their bug tracking, send the patch and probably wait for ages until it gets approved (because I have no reputation at upstream) and keeping a constant eye on the bug report, etc. The Gentoo maintainer has anyway an open eye with the development at upstream. He/She is probably better suited to handle the patch." Was I wrong with my assumption?
I don't have any particular contact with them, and they handle development on a mailing list rather than a bug tracker. Generally-speaking we invite users to send the fixes upstream themselves so they get the due credit, I can send it on your behalf if you want.
(In reply to comment #3) > Fixed in tree, thanks for the patch — please send it upstream though. Okay. I will do that. I have already another package (busybox) having the same issue with <sys/resource.h>. So at the end I need to register upstream with sys-libs/pam, sys-apps/busybox, etc... damn. Accounts everywhere just for submitting patches. I still think the package maintainer at Gentoo is better suited for that. I understand you forwarding me to upstream but somehow the whole bugs.gentoo.org bugzilla is full of issues that should/could be handled upstream. b.g.o should only be used for Gentoo related issues (such things as our init.d system, ebuilds, etc..). But it is not. It is used for way more. Ach! I should stop misusing b.g.o for my rant and shut up and send the patch upstream. :)
(In reply to comment #5) > I don't have any particular contact with them, and they handle development > on a mailing list rather than a bug tracker. Generally-speaking we invite > users to send the fixes upstream themselves so they get the due credit, I > can send it on your behalf if you want. Okay. I will send it. No problem.
