Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC
Bug 424920 - sys-libs/pam-1.1.5 failing to compile with glibc-2.16 and gcc-4.7.1
Summary: sys-libs/pam-1.1.5 failing to compile with glibc-2.16 and gcc-4.7.1
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: PAM Gentoo Team (OBSOLETE)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: glibc-2.16
  Show dependency tree
 
Reported: 2012-07-05 14:19 UTC by Stevan Bajić
Modified: 2012-07-05 16:45 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
pam-1.1.5-pam_unix_acct.patch (pam-1.1.5-pam_unix_acct.patch,321 bytes, patch)
2012-07-05 14:19 UTC, Stevan Bajić
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Stevan Bajić 2012-07-05 14:19:17 UTC
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
Comment 1 Stevan Bajić 2012-07-05 14:19:51 UTC
Created attachment 317302 [details, diff]
pam-1.1.5-pam_unix_acct.patch
Comment 2 Diego Elio Pettenò (RETIRED) gentoo-dev 2012-07-05 16:13:15 UTC
Most definitely glibc (as I know it works fine with gcc 4.7).

Did you send the patch upstream?
Comment 3 Diego Elio Pettenò (RETIRED) gentoo-dev 2012-07-05 16:18:46 UTC
Fixed in tree, thanks for the patch — please send it upstream though.
Comment 4 Stevan Bajić 2012-07-05 16:35:51 UTC
(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?
Comment 5 Diego Elio Pettenò (RETIRED) gentoo-dev 2012-07-05 16:40:23 UTC
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.
Comment 6 Stevan Bajić 2012-07-05 16:44:38 UTC
(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. :)
Comment 7 Stevan Bajić 2012-07-05 16:45:25 UTC
(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.