Re: [gentoo-embedded] glibc+iconv

[Sergey Mironov]

2011/10/14 Mike Frysinger <vapier@g.o>:
> 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