Summary: | >sys-apps/systemd-233 needs >=dev-util/gperf-3.1 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Ulenrich <ulenrich> |
Component: | Stabilization | Assignee: | Gentoo systemd Team <systemd> |
Status: | RESOLVED INVALID | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://github.com/systemd/systemd/pull/6541 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Ulenrich
2017-08-04 12:54:17 UTC
Do you experience any build failure with gperf-3.0? I'm fairly certain the NEWS file is wrong. Not personally experienced a build failure, because I have Gentoo~unstable. This is odd, never have seen such an announced requirement of version, when unnecessary ... ... Perhaps upstream systemd developers think of an enhanced security feature that gperf-3.1 provides? gperf-3.1 has nine years developement since gperf-3.0.4 ---gperf-3.1 NEWS * The 'len' parameter of the hash function and of the lookup function is now of type 'size_t' instead of 'unsigned int'. This makes it safe to call these functions with strings of length > 4 GB, on 64-bit machines. --- What about systemd dumps, or elsewhere: Is there needed any hash with >4GB ? (In reply to Ulenrich from comment #4) gperf is only used for strings that are defined at build time, none of which are more than a 100 bytes long. Anyway, upstream merged my revert of the NEWS change, so this was likely a mistake on their part. As a side note, I am using latest systemd with stable gperf-3.0 without issues |