Okay so here's the situation. uclibc is highly configurable and we can build it without iconv. We can still have a system with iconv support using dev-libs/libiconv the way fbsd does. Why? Because uclibc's iconv support is incomplete -- if your buidling a system via cross compile its fine, but on a uclibc system building uclibc itself, it fails. Its as yet incomplete. However, virtual/libiconv doesn't encode this option. It just says: RDEPEND="!elibc_glibc? ( !elibc_uclibc? ( dev-libs/libiconv ) )" which doesn say "use dev-libs/libiconv if uclibc is buidl with USE=-iconv". Okay so we tried: RDEPEND=" !elibc_glibc? ( elibc_uclibc? || ( dev-libs/libiconv sys-libs/uclibc[iconv] ) !elibc_uclibc? ( dev-libs/libiconv ) )" Only to discover that portage reasons something like this ... if USE=elibc_uclibc, then either dev-libs/libiconv or sys-libs/uclibc[iconv]. But as soon as it matches on the package uclibc, it says, okay now I want you to unmask iconv, which is not what we want. Okay so we tried DEPEND=" !elibc_glibc? ( elibc_uclibc? ( !iconv? ( dev-libs/libiconv ) ) !elibc_uclibc? ( dev-libs/libiconv ) ) " but this means importing IUSE=inconv to the virtual and i'm not sure that's a good idea because you may want iconv on everywhere except uclibc. The best solution so far is to modify the uclibc ebuild to encode a logic like this: if you don't want me to generate iconv then you can still get it by post depending on dev-libs/libiconv. So just add PDEPEND="!inconv? ( dev-libs/libiconv )" This will force the extra package if !iconv, so if you really want you can add iconv-ext to say, I want you to provide inconv externally: PDEPEND="!iconv? ( iconv-ext ( dev-libs/libiconv ) )" the latter smacks of useflag bloat. Finally, where does this really hit home? When trying to build with catalyst, stage1 misses dev-libs/libiconv even if it is in some packages file because its a stage1. (Maybe profile/package.build can help here, but I had no luck.) Reproducible: Always
(In reply to comment #0) > Finally, where does this really hit home? When trying to build with > catalyst, stage1 misses dev-libs/libiconv even if it is in some packages > file because its a stage1. (Maybe profile/package.build can help here, but > I had no luck.) The file name is "packages.ebuild", not "package.ebuild". Does it work if you spell it right?
I mean "packages.build", not "package.build".
(In reply to comment #2) > I mean "packages.build", not "package.build". I only spelled it wrong here. It does work. I still can't help but wonder if this logic shouldn't be in uclibc ebuild itself.
(In reply to comment #0) i don't think uclibc should be depending on libiconv at all. i certainly run systems w/out iconv and don't have a problem. like my personal server -- apache (including php), git, openvpn, ssh, and more. the lack of iconv isn't preventing this, and this is a fairly "full" build.
(In reply to comment #4) > (In reply to comment #0) > > i don't think uclibc should be depending on libiconv at all. i certainly > run systems w/out iconv and don't have a problem. like my personal server > -- apache (including php), git, openvpn, ssh, and more. the lack of iconv > isn't preventing this, and this is a fairly "full" build. Its at least python 3.2 that caused the issue. I had to bring in iconv support. I'll check later if this is coming from wide-unicode support or what. uclibc-amd64 ~ # ldd /usr/bin/python3.2 checking sub-depends for '/usr/lib/libpython3.2.so.1.0' checking sub-depends for '/usr/lib/gcc/x86_64-gentoo-linux-uclibc/4.6.3/libgcc_s.so.1' checking sub-depends for '/lib/libpthread.so.0' checking sub-depends for '/lib/libc.so.0' checking sub-depends for '/usr/lib/libintl.so.8' checking sub-depends for '/lib/libdl.so.0' checking sub-depends for '/lib/libutil.so.0' checking sub-depends for '/lib/libm.so.0' checking sub-depends for '/lib/libiconv.so.2' libpython3.2.so.1.0 => /usr/lib/libpython3.2.so.1.0 (0x00000000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-gentoo-linux-uclibc/4.6.3/libgcc_s.so.1 (0x00000000) libpthread.so.0 => /lib/libpthread.so.0 (0x00000000) libc.so.0 => /lib/libc.so.0 (0x00000000) libintl.so.8 => /usr/lib/libintl.so.8 (0x00000000) libdl.so.0 => /lib/libdl.so.0 (0x00000000) libutil.so.0 => /lib/libutil.so.0 (0x00000000) libm.so.0 => /lib/libm.so.0 (0x00000000) libiconv.so.2 => /lib/libiconv.so.2 (0x00000000) not a dynamic executable
this is a result of my uclibc config file and the way i've been doing things on the stage3 under /experimental/<arch>/uclibc. using the breakout library does mean having to add CFLAGS=-liconv and this works okay for all the bugs related to this.
