Currently dev-libs/libiconv has a series of keywords (~amd64 ~ppc ~sparc ~x86, plus stable amd64 and x86) that shouldn't be there. The library is _not_ supposed to be used on glibc, and if I understood solar well, this shouldn't be the case for uclibc, either. Something isn't right here, what people suggest we do? Thanks, Diego
Note: if solar can explain _what_ libiconv has to be used for in uclibc, it will reall help at this point, as every time I hear only half explanation ...
Well, when I was building stages based on uclibc (admittedly, it's been at least 6 months) lots of packages that were looking for libiconv would not compile, since uclibc didn't provide it.
By the way, it's stable on amd64/x86 because I asked for it. I was testing building release media with uclibc and it was required to get some of the stuff in livecd-stage1 to build/work.
Yes I remember that, but last I heard from solar, libiconv breaks uclibc somehow, although I never herd how and why. So unless someone can give me good reasoning if it breaks or it's needed, this is going to remain a mess. I'm ready to write the documentation on bsd's project page if someone gives me the pointers.
If you don't get a response, I can test it, but it'll be a little while. I'm up to my neck in release stuff at the moment and can't take the time out to build a complete uclibc set.
(In reply to comment #1) > Note: if solar can explain _what_ libiconv has to be used for in uclibc, it What do you want to know? I never suggested anybody use that package. libiconv does nothing for uclibc. It may help allow some packages to build but it's faulty. For embedded we have a mini-iconv which comes from mozilla code which we will probably use in place of full iconv at some point.. Let me add psm to the CC: as he may chime in.
If libiconv is installed and you recompile gcc, you will end up having gcc depending on libiconv (imagine now the scenario that you remove libiconv or update/downgrade to a non-compatible version). Do not know if this applies to glibc as well. This package also pulls in gettext and after this anything you build (despite USE=-nls, because too few ebuilds support that use-flag), will also depend on the libintl*.so libs that is for sure an overkill for embedded. in glibc land I knew of some package that does not like the iconv() implementation in glibc and wants libiconv, sorry, cant recall which. Anyways the glibc iconv() and libiconv iconv() are not fully compatible. The only package that really would need an iconv() implementation is glib-2* and due to the fact that a mini-iconv() added to glib-2 was refused by a glib-2 maintainer, this blocks anything that requires glib-2* (gnome suite) on uClibc The only current way out of this dillemma is to enable iconv() in uClibc (but that makes uClibc become much bigger, and that part is completely experimental, unsupported, unmaintained, the ebuild does not really do it correctly either) and there are packages that do not consider the uClibc internal iconv() good enough. I personally use 2 uClibc configs: 1. no iconv() in uClibc and add gettext-99999/libiconv-99999 to provided 2. iconv() in uClibc and add gettext-99999 to provided in both cases I use a fake libintl.h to get any packages build a 3. possibility is to enable libintl.* in uClibc, then gettext may be installed (because then it does not install the shared libs, only executables), but the nls implementation in uClibc does really nothing, it won't use any LC_MESSAGES/* files, thus not changing language on console. The resulting binaries will be bigger and there is no way back anymore, due to changed uClibc internals.
(In reply to comment #7) > If libiconv is installed and you recompile gcc, you will end up having gcc > depending on libiconv (imagine now the scenario that you remove libiconv or > update/downgrade to a non-compatible version). Yep this is the same we have on Gentoo/FreeBSD, that's why I always ensure that libiconv does not break on update, and why virtual/libiconv is in GCC depends already. > This package also pulls in gettext and after this anything you > build (despite USE=-nls, because too few ebuilds support that use-flag), will > also depend on the libintl*.so libs that is for sure an overkill for embedded. Uhm no libiconv does not bring gettext. There *could* have been a circular dependency, but I've disabled NLS in libiconv forcefully to avoid it. NLS useflag, is something I always try to make sure is present, as we have the same problem with Gentoo/FreeBSD. I'm more interested to fix that rather than working it around, so that might help if we do together. > in glibc land I knew of some package that does not like the iconv() > implementation in glibc and wants libiconv, sorry, cant recall which. Haven't found one yet. I think samba didn't like older glibc's iconv(), but it's okay with current glibc. So to sum it up, uclibc has no use for libiconv, and thus it can be relied only as a Gentoo/Alt package, correct? In that case, I'd ask for dropping keywords for Linux side. About the nls useflag, I'll be fighting about it as much as I can... I'm having trouble now with Python 'automagic' dependent on libintl, that makes impossible to get rid of libintl for good on g/fbsd.
I can get rid of any libintl dependency, all the libintl provided functions are replaced by dummy macros, so why can't you do the same on *BSD? On uClibc on contrary, we do not want nls use flag at all, I wonder why you need to enforce it on *BSD even if you do not have the base system providing the functionality. The nls use flag is for me: *textdomain*() and *gettext(), if you do not have in libc, then you can have it provided by gettext, but this is what I try to avoid on uClibc. So you don't think I do not know what I am speaking about: I have built the whole gnome suite against uClibc without iconv() in uClibc and without libiconv and gettext installed, show me an app that does not want to build without libintl. I do not know how many used libiconv to get glib2 working on uClibc, they won't be happy for sure if you do not allow them to do it First I would solve glib2 to work without iconv(), after that you can even remove libiconv from system, there is no real need for it.
Working nls useflag for Gentoo/FreeBSD, with proper dependencies over virtual/libintl, is something we need to be safe that the dep tree is correct. About uclibc, I just want to have a simple statement about if it's actually needed (in which case I'd ask for a new stable in a month for now) or if it's not (in which case I'd ask for removing all the keywords that are not for FreeBSD). I suppose that proper --disable-nls support is something you also need, to avoid having failure to link because of that, so if this can be done together is likely to take less time. If I'm wrong here, well okay, I'll still be working on it for G/FreeBSD anyway. The problem right now is, virtual/libiconv is currently reporting dev-libs/libiconv for anything but glibc/uclibc. I have some virtual/libiconv to use in packages like rsync, but I don't want to hinder uclibc support, so I need to know _exactly_ what should I ask there... if !elibc_uclibc?( virtual/libiconv) or simply virtual/libiconv and assuming that elibc_uclibc has it.
(In reply to comment #7) > The only package that really would need an iconv() implementation is glib-2* > and due to the fact that a mini-iconv() added to glib-2 was refused by a glib-2 > maintainer, this blocks anything that requires glib-2* (gnome suite) on uClibc Thanks for the reminder. It was glib that caused it. I actually had worked around it in my latest builds by not using anything that required glib. I know that irssi was one of the applications that required it. Anyway, since I was the one that requested it be stabilized, I see no problem with removing it. As for it being given KEYWORDS, at all... no clue there, but if you ask my opinion, I say strip them.
list of apps that somehow need treatment due to missing iconv() mc/glib-2*/libcdio/evolution-data-server/gal/gpe-edit/gpe-po/gpe-sketchbook/ flac/libcddb/lm_sensors/dillo/mozilla*/seamonkey/gecko-sdk/xulrunner/ecore
from the above list mc/glib-2*/lm_sensors/dillo need an iconv() implementation, the others need only changes to ebuild (most of them run autoconf and due to missing iconv.m4, they fail, AM_ICONV or similar has to removed before eauto* is run), the whole emerge -e system stuff does not need iconv(), rsync for ex.
rsync links to libiconv if it's found, so i'd say to just put it as a !elibc_uclibc dep, so that at least we have a proper handling on gentoo/freebsd. A similar thing happens to Python with libintl, so I suppose the same would apply to that. So, nobody have problems if I go dropping 1.9 from portage?
No objections punt the pkg if you desire.
Okay, I've dropped libiconv 1.9 from tree. If arches want to remove their ~keyword from the package, please do so.
~x86 removed from 1.11
~sparc nuked!
~ppc nuked
Hi all, I was going to open a bug to ask for ~x86 to be added to libiconv then I saw all these comments. :( If I install libiconv on a uclibc system, it is letting me build firefox and a whole lot of other stuff (mostly because of glib-2) that I couldn't get otherwise. Is this not a good thing for people who want to use uclibc as an alternative to glibc? If there are added dependencies to gcc or other packages, can't that just be documented and warnings given? Thanks.
Closing this.
