2011/10/14 Mike Frysinger <[email protected]>: > 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. > -mike >
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? 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. Sergey
