It has become very difficult to build a gentoo system using uclibc instead of glibc. The immediate cause of this is a change in the ebuild for virtual/libiconv. The previous version of the ebuild was broken, and had no dependencies when using uclibc. This was changed, however, so that it depended on either a uclibc with the iconv USE flag, or dev-libs/libiconv. This change is correct, as far as it goes, but in practice is difficult, as dev-libs/libiconv is masked for uclibc profiles, an iconv support has been removed from the most recent uclibc, and was very difficult to get working in older versions of uclibc. the reason this has a major impact on the system is that many versions of gcc depend on virtual/libiconv. When the virtual ebuild was broken so it was always satisfied, gcc worked properly, so it must be assumed that this dependency is bogus. I see three approaches to fixing this, it may take some combination of the three, though: i) Find out why gcc needs libiconv, and potentially remove the dependency; ii) find out why dev-libs/libiconv is masked, and possibly unmask it; iii) add the iconv use flag back into uclibc I beleive a change has been checked in for the virtual to restore something similar to the previous state, but this is only a band-aid approach, as it only works if the dependency isn't really needed (as in the gcc case) Reproducible: Always Steps to Reproduce: 1. emerge gcc 2. 3. Actual Results: !!! One of the following packages is required to complete your request: - sys-libs/uclibc-0.9.30.1-r1 (Change USE: +iconv) (dependency required by "sys-devel/gcc-4.3.4" [ebuild]) (dependency required by "gcc" [argument]) Expected Results: Successful emerge
Please add emerge --info
this is already fixed in the tree from what i can see
If this is the fix that was discussed on the #gentoo-embedded channel, it only restores the previous broken virtual/libiconv state, with nicer syntax. This has the effect of telling portage that uclibc supplies libiconv even when it doesn't. The reason this works for gcc is that it appears that gcc doesn't really need libiconv, but the fix will have the effect of breaking anything that DOES need libiconv, such as glib. A correct fix would require some way of supplying libiconv with uclibc, either by unmasking the dev-libs/libiconv ebuild, or re-adding the iconv USE flag to uclibc. It would also be a good idea to remove the dependency from gcc, as it seems it isn't really necessary.
Please keep on topic. The bug filed was about the eclass. That has been addressed already. There are many reasons why libiconv.so should not be used on a uclibc system that go beyond the scope of the bug filed here.
let's ask Diego why he thinks all gcc versions need virtual/libiconv since he added the dep
It's an automagic dep.
then can we make it automagic based on some general system targets instead of everyone ? otherwise, it kind of reduces the usefulness of virtual/libiconv.
I'd be happy to make it go away as an automagic dep myself; if you can find where it's used. Unfortunately I'm *already* trying to make sense of the gcc build system and my current feeling is “why me?“. So yeah at the time it was the simplest choice, nowadays it's probably something that we should be looking to solve.
ive never seen a build error, nor seen a reported one (that i remember), so you're the only one apparently seeing this. so at least a log of a representative failure would be good.
(In reply to comment #4) > Please keep on topic. The bug filed was about the eclass. That has been > addressed already. There are many reasons why libiconv.so should not be used on > a uclibc system that go beyond the scope of the bug filed here. > The problem is that the version if the virtual that broke the builds is the correct one, the new (and previous) versions are both broken. We shouldn't be saying we supply libiconv if we aren't. I suppose this should be opened as three or four separate bugs, one for each package that is involved, and make them depend on each other. Technically, the virtual/libiconv ebuild is the only one that shouldn't be fixed...
The problem is not build, the problem is that if libiconv is removed _after_ gcc is merged… it breaks.
(In reply to comment #11) > The problem is not build, the problem is that if libiconv is removed _after_ > gcc is merged… it breaks. Which is one of the reasons if we ever link to libiconv on uclibc we would rather link to the *.a file (and preferably from a non standard search path). Problem becomes that many other pkgs will see libiconv support and link to it if we like it or not. Outside of glib:2 not many things really need it.
In our experiment, libiconv is not generally used if not needed, but gcc links to it automatically; the same goes for gettext. The point at the end is the same, let's just fix the bloody gcc's automagic dep, and we're done with that. The rest can be applied as it comes through.
i'm trying to crosscompile gcc on a amd64 for arm (netwinder) and i get this error: amd64 ~ # armv4l-unknown-linux-gnu-emerge gcc Calculating dependencies... done! !!! All ebuilds that could satisfy "dev-libs/libiconv" have been masked. !!! One of the following masked packages is required to complete your request: - dev-libs/libiconv-1.13.1 (masked by: missing keyword) For more information, see the MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. (dependency required by "sys-devel/gcc-4.4.2" [ebuild]) (dependency required by "gcc" [argument]) Is this the same problem?
(In reply to comment #11) > The problem is not build, the problem is that if libiconv is removed _after_ > gcc is merged… it breaks. What I don't understand is why that means dev-libs/libiconv has to be masked? If you want to use that library on a uClibc system then why would you remove it? gcc will also break if you remove gmp, how is that any different? Diego?
(In reply to James Le Cuirot from comment #15) > (In reply to comment #11) > > The problem is not build, the problem is that if libiconv is removed _after_ > > gcc is merged… it breaks. > > What I don't understand is why that means dev-libs/libiconv has to be > masked? If you want to use that library on a uClibc system then why would > you remove it? gcc will also break if you remove gmp, how is that any > different? Diego? To be clear, this the case on profiles/uclibc, but nowadays I'm building uclibc stages useing profiles/default/linux/uclibc and adding dev-libs/libiconv as the provider. I wonder what we should do with the profile/uclibc profiles.
(In reply to solar from comment #4) > Please keep on topic. The bug filed was about the eclass. That has been > addressed already. There are many reasons why libiconv.so should not be used > on a uclibc system that go beyond the scope of the bug filed here. Hi solar, I know you haven't been around for a while and its off topic, but why can't we use libiconv on uclibc?
dev-libs/libiconv under uClibc generally speaking is fine -- as long as we have blockers in place for when uClibc provides iconv support itself we should look at phasing out the embedded/ and uclibc/ subdirs of profiles/ once we know default/linux/uclibc/ covers everything
uclibc profiles are gone in https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3dc19a78c69028071a12377eac37c86226a4c6c2 I suggest leaving embedded profiles as-is for a while as crossdev defaults using those. crossdev also sets overrides to be usable on non-glibc libc as well: https://gitweb.gentoo.org/proj/crossdev.git/commit/?id=393e1cd0c6d3ac81fa166bafe6065d42849f622c