To reproduce: `emerge system` with profile uclibc/amd64 Reproducible: Always Steps to Reproduce:
Please post your `emerge --info', and proper steps to reproduce. I had a superficial look around the profiles directory and I would think that uclibc/amd64/ inherits from its parent, uclibc/, where the file virtuals does clearly define the virtual/libc virtual.
Created attachment 191929 [details] emerge --info
To reproduce: # emerge -pv virtual/libc These are the packages that would be merged, in order: Calculating dependencies... done! emerge: there are no ebuilds to satisfy "virtual/libc".
It seems that the virtual is being recognized. It doesn't make a difference if the profile is set to just uclibc even.
I'm having exactly the same problem with the profile uclibc/x86. I did notice something odd in the output of eix for sys-libs/uclibc though: * sys-libs/uclibc Available versions: (i686-pc-linux-uclibc) 0.9.27-r1!s 0.9.28.3!s 0.9.28.3-r3!s ~0.9.28.3-r7!s ~0.9.30!s ~0.9.30.1!s ~0.9.30.1-r1!s {build crosscompile_opts_headers-only debug hardened iconv ipv6 minimal nls pregen savedconfig ssp uclibc-compat userlocales wordexp} Homepage: http://www.uclibc.org/ Description: C library for developing embedded Linux systems The "Available versions" line suggests that uclibc is only available for i686-pc-linux-uclibc, while the system I'm compiling for is i586-pc-linux-glibc (it's geode-based) and the reporter of this bug is compiling for x86_64-gentoo-linux-uclibc. Perhaps the problem is there? Also, when I emerge uclibc manually, it does build, but I receive a curious QA notice: >>> Installing sys-libs/uclibc-0.9.28.3-r3 * QA Notice: Expected SLOT='i686-pc-linux-uclibc', got '0'
The ebuild features the following code snippets: # Handle the case where we want uclibc on glibc ... if [[ ${CTARGET} == ${CHOST} ]] && [[ ${CHOST} != *-uclibc* ]] ; then export UCLIBC_AND_GLIBC="sitting in a tree" export CTARGET=${CHOST%%-*}-pc-linux-uclibc fi ... if [[ -n $CTARGET && ${CTARGET} != ${CHOST} ]]; then DEPEND="" PROVIDE="" SLOT="${CTARGET}" else DEPEND="virtual/os-headers app-misc/pax-utils" PROVIDE="virtual/libc" SLOT="0" fi So if CTARGET != CHOST (which might be from uclibc-and-glibc mode, because you emerge-info shows you on -gentoo-linux-uclibc rather than -pc-linux-uclibc), and so it won't PROVIDE libc. That doesn't explain to me why you'd get put in uclibc-and-glibc mode, but maybe we've got enough for the embedded guys to advise on, so I'm gonna CC it to them...
(In reply to comment #6) > The ebuild features the following code snippets: ... > So if CTARGET != CHOST (which might be from uclibc-and-glibc mode, because you > emerge-info shows you on -gentoo-linux-uclibc rather than -pc-linux-uclibc), > and so it won't PROVIDE libc. That doesn't explain to me why you'd get put in > uclibc-and-glibc mode, but maybe we've got enough for the embedded guys to > advise on, so I'm gonna CC it to them... I think this is a portage error that we have seen before and that might not be fixable. Adding zac to the CC: to confirm.
I have the same problem with the profile uclibc/mips with mips-unknown-linux-uclibc CHOST If it couldn't fixable, theres are any workaround?
The problem is that portage expects the ebuild to define PROVIDE during the "depend" phase when metadata is generated and cached for dependency calculations. In this case, the ebuild is producing empty PROVIDE. I suppose that we can make portage simply ignore the PROVIDE variable, since it seems to be a constant source of trouble for embedded people. If we can rely on the profile virtuals settings then the PROVIDE variable is really redundant anyway.
(In reply to comment #9) > The problem is that portage expects the ebuild to define PROVIDE during the > "depend" phase when metadata is generated and cached for dependency > calculations. In this case, the ebuild is producing empty PROVIDE. I suppose > that we can make portage simply ignore the PROVIDE variable, since it seems to > be a constant source of trouble for embedded people. If we can rely on the > profile virtuals settings then the PROVIDE variable is really redundant anyway. This sounds ideal.
Thinking about this a little more, it seems like this can be most cleanly handled with something like PROVIDE="elibc_uclibc? ( virtual/libc )". However, it requires the fix from bug #82488 which is fixed in svn but hasn't been released yet.
The fix from bug #82488 doesn't seem to be required in this case. I've updated all the ebuilds to use PROVIDE="elibc_uclibc? ( virtual/libc )" and it seems to work fine in a uclibc/x86 chroot with portage-2.1.6.13.
Yes, this fixes the problem for me too. Thanks.
Works for me too. Many Thx!
