Hi, the attached ebuild is for libiconv 1.9.2. Currently libiconv is hard masked as it's conflicts with glibc (it tries to replace glibc headers), because libiconv is intended to be used where glibc is not used. This is the case for (for example) *bsd, darwin (and macos, which is shipped with it) and uclibc systems. dev-libs/glib for example needs libiconv if glibc is not used (so the next bug for it will depend on this one) Adding this to portage will make non-glibc system able to install it and use it as needed and won't create problems for linux users. HTH, Diego
Created attachment 53041 [details] dev-libs/libiconv-1.9.2 ebuild
spider: please advise if we setup libiconv to simply block glibc, cant we unmask it so other systems can use it ? DEPEND=!sys-libs/glibc
Yeah, that could be done. The problem is that it clobbers glibc's files. Make sure you test it with various libc's and the collision-detection FEATURE set in portage to prevent it from fucking other platforms up that have the build. (macos / BSD come to mind as likely to have an implementation)
$(use_with pic) <-- this can be a bad thing. Often you will want to force pic behavior but never remove the default behaviour. So for that pic part of the ebuild I think it should key off of use pic && myconf="$myconf --enable/with-pic" so.. lets look at it like this. libiconv is a lib (ET_DYNC shared object) and all libs need to be compiled pic. So really --enable-/--with-/pic should probably be enabled all the time.
i cant vouch for darwin / bsd libc's but i'm pretty sure we can use this with uclibc psm: you've been hacking on NLS stuff lately ... could you check this out ? the ebuild should drop the pic line and change the 'emake' to 'make' in src_install() ...
Created attachment 53081 [details] Ebuild without pic and little changes I've removed pic useflag and let configure decide itself. I also changed the description line with something more appropriate. I changed emake install into make install. Least I add block on glibc. Not sure about macosx, but this is not only working, but also needed to run gentoo/freebsd (for some packages at least, for example glib2).
Hmm, I keep forgetting when in the installation part DEPEND vs RDPEND is checked. Ie, will a Glibc system break if I do: ebuild libiconv-1.9.ebuild package emerge /usr/portage/packages/libiconv-1.9.tbz2 or not? DEPEND vs. RDEPEND conflicts make my head spin. ; ( or wait, the RDEPEND is empty and therefore inherits the DEPEND?
without RDEPEND they should be both set at ! sys-libs/glibc
libiconv does not work w/ some apps for uclibc I would rather use the integrated iconv() implementation
If nobody wants/can take care of it, I'd like to, it's really needed on non-glibc desktop systems.
Sure, I don't mind. As long as you make sure that the various desktop-parts actually -work- with it ( gnome-vfs was one of the mongler and dying things with i ) its okay. Though in the normal case (glibc installed) this isn't an issue for people.
Ok then I'll take care of libiconv in future. I'm going to build the g/fbsd system on this so it will be tested with many apps.
