| Summary: | sys-libs/glibc-2.26 doesn't build the rpc interface even for USE=rpc | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Andreas K. Hüttel <dilfridge> |
| Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED CANTFIX | ||
| Severity: | normal | CC: | reuben-gentoo-bugzilla |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 381391, 628768 | ||
|
Description
Andreas K. Hüttel
2017-08-23 21:26:42 UTC
This bug is a big problem for me as well - and I'll explain why, for anyone else who comes looking. Currently Busybox (util-linux component specifically) requires rpc.h, and this file is no longer present in glibc-2.26 by default. But this means that since upgrading to glibc-2.26, the previously working Busybox suddenly fails to compile, on account of the missing rpc.h include. The follow on effect is that without Busybox I also cannot rebuild an initramfs (and therefore cannot upgrade my kernel). I could potentially work around this Busybox breakage by building obsolete RPC support in glibc, if as per the subject of this bug report, this USE flag wasn't broken. It's worse than broken though, because it looks like it should work but come compile time it actually doesn't work at all (it would have been easier to work out the root cause of my problems if the USE flag simply wasn't there in the first place!) Downgrading glibc even to 2.25 breaks things really badly, so that's not an option either. And yes, I know the root cause of this is is a bug with Busybox, but this glibc USE flag takes away the one sane workaround I could use to keep my system building. The only remaining workaround I have at my disposal is to manually hack up /usr/portage/eclass/toolchain-glibc.eclass to manually enable the obolete-rpc configure option. I've tested this, and with that hack in place, Busybox can build the components it requires and I can build and initramfs and then upgrade/reboot the new kernel. But all in all, very very ugly. (In reply to Reuben Farrelly from comment #1) > This bug is a big problem for me as well - and I'll explain why, for anyone > else who comes looking. > Well, to be honest, that's why you usually shouldn't use unkeyworded ebuilds (much less an unkeyworded glibc). I'm aware of rpc/rpc.h, and we need some fix for it. Just that there are also other urgent things. This bug is now getting closed since 2.26 has the rpc useflag masked and in 2.26-r1 it is gone entirely. Working on the replacement stack. |