rng-tools requires argp functions which only exist in glibc. These functions have been broken out into a separate "argp-standalone" package and linking to this will allow rng-tools to be built on embedded platforms A small patch is required to tell the build it needs to use this external library. I have depended on the USE flag: elibc_uclibc, in order to decide if we need to use the external argp library Reproducible: Always Steps to Reproduce:
Created attachment 209482 [details, diff] rng-tools-uclibc.patch
This bug depends on bug #292189 for the sys-libs/argp-standalone ebuild
please ping base-system after the library has been added, not before.
i don't think this is the right way to go about things. we need something that scales and doesn't involve modifying every ebuild.
Do you mean you want it submitting upstream to uclibc? Note what else do we have that will ever use it? Can probably answer that question by looking in alpine-linux tree (or perhaps openembedded/wrt?) Would your opinion change if we only have one build ever use it?
(In reply to comment #5) > Do you mean you want it submitting upstream to uclibc? > > Note what else do we have that will ever use it? Can probably answer that > question by looking in alpine-linux tree (or perhaps openembedded/wrt?) > > Would your opinion change if we only have one build ever use it? rng-tools should be patched to rework the call to argp with something more mainline, preferably posix compliant.
Surely that's just swapping one patchset for another? How does it scale better? At least argp_standalone is a drop in library for a rarely required problem that doesn't consume much additional on disk space (which is the main reason it has been declined from uclibc mainline previously) Note: I'm not disagreeing, I just don't understand what is the core problem so we can solve *that*?
(In reply to comment #7) > Surely that's just swapping one patchset for another? How does it scale > better? I wasn't addressing that. Anyhow, I looked at the code and scratch my idea in comment 6 since there are multiple calls to argp_* friends. I don't know how many other packages use argp but it might be worth briging it up on the uclibc list. Since the arpg code has been broken out, it could be important into uclibc.
(In reply to comment #5) i was thinking argp was in POSIX ... it is not. scanning my system shows few packages using it (like ~5 out of ~2000), so it prob won't be so bad. we shouldn't be doing this based on USE=uclibc though. for autotool packages, we should check to see if the C library provides argp_parse and if not, fall back to the argp library.
Created attachment 313197 [details, diff] Patch against configure.ac to test for who provides argp I tested this on a glibc system and a uclibc system with/without argp-standalone. It works as expected. I'll get the patches against the ebuilds up in a bit.
Created attachment 313199 [details, diff] Patch against rng-tools-2-r1 to apply the test-for-argp.patch
Created attachment 313201 [details, diff] Patch against rng-tools-3 to apply the test-for-argp.patch
ping nelchael
Patch added with permission. @Ed, please test and reopen if this is still a problem. *rng-tools-3-r1 (19 Jul 2012) 19 Jul 2012; Anthony G. Basile <blueness@gentoo.org> +rng-tools-3-r1.ebuild, +files/test-for-argp.patch: Patch configure.ac to search for arpg in glibc or libargp, bug #292191