| Summary: | sys-libs/libcap-2.25 with dev-util/gperf-3.1: ./_caps_output.gperf:71:80: error: unknown type name ‘size_t’ | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | dwfreed <dwfreed> |
| Component: | Current packages | Assignee: | Tony Vroon (RETIRED) <chainsaw> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | anarchy, blueness, dzany, email, even.more.spam.for.me, floppym, gebauer.andy, gem, itumaykin+gentoo, kdvgent, kentnl, krinpaus, leonchik1976, O01eg, orzel, pageexec, pvdabeel, xaviermiller, xmw |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 604878 | ||
| Attachments: |
build.log
emerge --info '=sys-libs/libcap-2.25::gentoo' libcap-2.25.ebuild.diff fix build with gperf-3.1 libcap-2.25-gperf.patch |
||
Created attachment 458872 [details]
emerge --info '=sys-libs/libcap-2.25::gentoo'
Adding blueness as gperf maintainer, as this appears to be a general issue with gperf-3.1 (eudev fails to build as well). Created attachment 459002 [details, diff]
libcap-2.25.ebuild.diff
Possible fix which just disables the gperf stuff in libcap. Dunno if we wanna go this route though or just want to put this behind a USE flag.
Any thoughts?
(In reply to dwfreed from comment #0) > downgrading gperf to 3.0.4 or removing gperf fixes the problem. Thanks, that worked for me. (In reply to Lars Wendler (Polynomial-C) from comment #3) > Created attachment 459002 [details, diff] [details, diff] > libcap-2.25.ebuild.diff > > Possible fix which just disables the gperf stuff in libcap. Dunno if we > wanna go this route though or just want to put this behind a USE flag. > > Any thoughts? Seems reasonable. This issue also affects sys-libs/libcap-2.24* as well, so I think the real issue is in gperf, not libcap. (In reply to Joshua Kinard from comment #5) > I think the real issue is in gperf, not libcap. gperf changed the API on its generated code. libcap will need to adjust. (In reply to Lars Wendler (Polynomial-C) from comment #3) I would do either of 2 things: 1. Fix the gperf code to work with gperf-3.1 and depend on gperf unconditionally. 2. Disabled gperf unconditionally. Adding a USE flag seems like overkill. Created attachment 460354 [details, diff]
fix build with gperf-3.1
Here's a patch to make gperf-3.1 work.
(In reply to Mike Gilbert from comment #8) > Created attachment 460354 [details, diff] [details, diff] > fix build with gperf-3.1 I sent this upstream (morgan at kernel.org). I'll let you know how he responds. Created attachment 462080 [details, diff]
libcap-2.25-gperf.patch
Adjusted your patch to apply to the current "no perl" ebuild, this compiles & builds.
[master 3e68f63c6d] sys-libs/libcap: Patch & research by Mike "floppym" Gilbert to allow compilation against gperf 3.1; ported to no-perl Makefile by me. Closes bug #604802 by dwfreed. 2 files changed, 18 insertions(+) create mode 100644 sys-libs/libcap/files/libcap-2.25-gperf.patch (In reply to Tony Vroon from comment #11) > [master 3e68f63c6d] sys-libs/libcap: Patch & research by Mike "floppym" > Gilbert to allow compilation against gperf 3.1; ported to no-perl Makefile > by me. Closes bug #604802 by dwfreed. > 2 files changed, 18 insertions(+) > create mode 100644 sys-libs/libcap/files/libcap-2.25-gperf.patch What about gperf being an automagic dep for libcap? (In reply to Coacher from comment #12) it isn't. gperf is used at build time only to generate a small source file (a hash table lookup). if gperf isn't available, libcap falls back to using a plain list of cap names. it's a minor perf increase to use gperf (probably not measurable), but has no impact on the functionality of the installed files. *** Bug 638664 has been marked as a duplicate of this bug. *** |
Created attachment 458870 [details] build.log libcap 2.25 fails to build if gperf 3.1 is installed (this is an automagic dep, btw); downgrading gperf to 3.0.4 or removing gperf fixes the problem.