Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 297229 - virtual/libiconv vs sys-libs/uclibc[iconv] vs sys-devel/gcc
Summary: virtual/libiconv vs sys-libs/uclibc[iconv] vs sys-devel/gcc
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo non-Linux Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-12-16 22:08 UTC by A. Craig West
Modified: 2019-01-27 11:05 UTC (History)
8 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description A. Craig West 2009-12-16 22:08:16 UTC
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
Comment 1 Stefan Behte (RETIRED) gentoo-dev Security 2009-12-18 15:13:35 UTC
Please add emerge --info
Comment 2 SpanKY gentoo-dev 2009-12-18 16:35:45 UTC
this is already fixed in the tree from what i can see
Comment 3 A. Craig West 2009-12-18 17:05:15 UTC
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.
Comment 4 solar (RETIRED) gentoo-dev 2009-12-18 17:23:13 UTC
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.
Comment 5 SpanKY gentoo-dev 2009-12-18 18:02:35 UTC
let's ask Diego why he thinks all gcc versions need virtual/libiconv since he added the dep
Comment 6 Diego Elio Pettenò (RETIRED) gentoo-dev 2009-12-18 18:07:57 UTC
It's an automagic dep.
Comment 7 SpanKY gentoo-dev 2009-12-18 18:16:58 UTC
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.
Comment 8 Diego Elio Pettenò (RETIRED) gentoo-dev 2009-12-18 18:27:42 UTC
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.
Comment 9 SpanKY gentoo-dev 2009-12-18 18:36:06 UTC
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.
Comment 10 A. Craig West 2009-12-18 18:43:45 UTC
(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...
Comment 11 Diego Elio Pettenò (RETIRED) gentoo-dev 2009-12-18 18:55:21 UTC
The problem is not build, the problem is that if libiconv is removed _after_ gcc is merged… it breaks.
Comment 12 solar (RETIRED) gentoo-dev 2009-12-18 20:04:08 UTC
(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.
Comment 13 Diego Elio Pettenò (RETIRED) gentoo-dev 2009-12-18 20:07:26 UTC
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.
Comment 14 Gruffi 2010-01-17 18:06:17 UTC
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?
Comment 15 James Le Cuirot gentoo-dev 2012-04-17 22:31:45 UTC
(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?
Comment 16 Anthony Basile gentoo-dev 2016-03-02 10:01:37 UTC
(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.
Comment 17 Anthony Basile gentoo-dev 2016-03-02 10:03:16 UTC
(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?
Comment 18 SpanKY gentoo-dev 2016-05-23 21:14:27 UTC
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
Comment 19 Sergei Trofimovich (RETIRED) gentoo-dev 2019-01-27 11:05:29 UTC
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