Bug 604802 – sys-libs/libcap-2.25 with dev-util/gperf-3.1: ./_caps_output.gperf:71:80: error: unknown type name ‘size_t’

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description dwfreed 2017-01-06 03:32:05 UTC]

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.

[Comment 1 dwfreed 2017-01-06 03:32:46 UTC]

Created attachment 458872 [details]
emerge --info '=sys-libs/libcap-2.25::gentoo'

[Comment 2 dwfreed 2017-01-06 03:49:26 UTC]

Adding blueness as gperf maintainer, as this appears to be a general issue with gperf-3.1 (eudev fails to build as well).

[Comment 3 Lars Wendler (Polynomial-C) (RETIRED) 2017-01-07 02:02:03 UTC]

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?

[Comment 4 Gary E. Miller 2017-01-13 23:18:26 UTC]

(In reply to dwfreed from comment #0)
> downgrading gperf to 3.0.4 or removing gperf fixes the problem.

Thanks, that worked for me.

[Comment 5 Joshua Kinard 2017-01-15 06:32:49 UTC]

(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.

[Comment 6 Mike Gilbert 2017-01-16 17:06:42 UTC]

(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.

[Comment 7 Mike Gilbert 2017-01-16 17:08:30 UTC]

(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.

[Comment 8 Mike Gilbert 2017-01-16 17:13:03 UTC]

Created attachment 460354 [details, diff]
fix build with gperf-3.1

Here's a patch to make gperf-3.1 work.

[Comment 9 Mike Gilbert 2017-01-16 17:32:03 UTC]

(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.

[Comment 10 Tony Vroon (RETIRED) 2017-02-01 10:03:58 UTC]

Created attachment 462080 [details, diff]
libcap-2.25-gperf.patch

Adjusted your patch to apply to the current "no perl" ebuild, this compiles & builds.

[Comment 11 Tony Vroon (RETIRED) 2017-02-01 14:42:11 UTC]

[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

[Comment 12 Coacher 2017-02-02 07:26:20 UTC]

(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?

[Comment 13 SpanKY 2017-02-09 15:58:11 UTC]

(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.

[Comment 14 Thomas Deutschmann (RETIRED) 2017-11-25 16:23:18 UTC]

*** Bug 638664 has been marked as a duplicate of this bug. ***