On Friday 14 October 2011 06:11:40 Sergey Mironov wrote:
> 2011/10/14 Mike Frysinger:
> > On Thursday 13 October 2011 19:30:14 Sergey Mironov wrote:
> >> 2011/10/14 Mike Frysinger:
> >> > On Thursday 13 October 2011 15:15:40 Sergey Mironov wrote:
> >> >> Hello. I have my arm-unknown-linux-gnueabi system which uses glibc
> >> >> and busybox. Recently I realised that iconv program doesn't exist in
> >> >> the tree. I've compared host's and target's glibc file lists and
> >> >> found that arm's version doesn't install anything to
> >> >> /usr/arm-unknown-linux-gnueabi/usr/bin. What can be the cause of
> >> >> this? Small C program shows that iconv_open function returns error
> >> >> code just like if there is no iconv at all. How shoud I make arm's
> >> >> iconv work?
> >> > 
> >> > see glibc's files/eblits/src_compile.eblit:
> >> >        is_crosscompile && sed -i '1ibuild-programs = no' config.make
> >> > 
> >> > i imagine disabling that line will get you `iconv`
> >> 
> >> Thanks, I will try it!  Am I understand correctly that iconv itself
> >> (library, not program) is a part of glibc and it is not possible to
> >> exclude it during the build? So despite the lack of program I should
> >> still have fully functional library.
> > 
> > your understanding is correct, however ........
> > 
> > iconv() is part of glibc but it relies on all of the gconv shared libs
> > found in /usr/$CTARGET/usr/lib/gconv/ to do its actually work.  which we
> > also incidentally delete when building the cross-compiler glibc (see
> > src_install.eblit and look for "gconv").
> > 
> > you aren't the first person to find this behavior undesirable, and when i
> > implemented it, it was more of "let's save space on things i don't think
> > anyone will use".  but if people are using it, then installing these
> > things probably makes sense.
> 
> Well, maybe I really want something strange. I guess, people often
> install another, non-cross-compiled version of glibc on top of initial
> one. I've tried to do so, but found that cross-emerge complains about
> conflicts - it simply doesn't treat initial glibc as a package
> installed on target. I saw 2 ways - either edit package.provided and
> don't install new glibc or disable conflicts detection and overwrite
> some target's  /lib* and /usr/lib/* files. I've chosen first way since
> I am afraid of getting a mess of two glibc's compiled with different
> tools. But how do you (or other people) act in this situation?

indeed, this is the current wonky behavior.  i guess the thing to do would be 
two fold:
	- remove the disabling of tools/supplemental files so the cross-compiler 
glibc has all the same files as sys-libs/glibc
	- have crossdev automatically add a package.provided entry to the 
/usr/$CTARGET/etc/ tree for sys-libs/glibc

> By the way, I also had to handcopy libstdc++.so from
> /usr/lib/gcc/$CTARGET to /usr/$CTARGET/lib to make C++ programs work.
> It is another thing which makes me thinking of installig full glibc on
> top of cross-one.

yes, the /usr/$CTARGET tree has no gcc files installed at all.  in native 
installs, we've got /etc/env.d/ which adds the internal gcc paths via LDPATH 
to ld.so.conf, and then ldso at runtime finds libstdc++.so and friends.  but 
gcc is not installed at all in /usr/$CTARGET.  in this case, you should be 
able to emerge gcc into /usr/$CTARGET since none of the cross-compiler gcc 
files should be in there ...
-mike