Summary: | virtual/libiconv vs sys-libs/uclibc[iconv] vs sys-devel/gcc | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | A. Craig West <acraigwest> |
Component: | [OLD] Core system | Assignee: | Gentoo non-Linux Team <alt> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | blueness, chewi, embedded, flameeyes, gruffivk, pinkbyte, toolchain, vapier |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
A. Craig West
2009-12-16 22:08:16 UTC
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 |