Gentoo Logo
Gentoo Spaceship

Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-embedded
Lists: gentoo-embedded: < Prev By Thread Next > < Prev By Date Next >
To: Mike Frysinger <vapier@g.o>
From: Sergey Mironov <ierton@...>
Subject: Re: glibc+iconv
Date: Fri, 14 Oct 2011 14:11:40 +0400
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 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.


Re: glibc+iconv
-- Mike Frysinger
-- Sergey Mironov
Re: glibc+iconv
-- Mike Frysinger
Re: glibc+iconv
-- Sergey Mironov
Re: glibc+iconv
-- Mike Frysinger
Lists: gentoo-embedded: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: glibc+iconv
Next by thread:
Re: glibc+iconv
Previous by date:
Re: GCC/LLVM-GCC targeting Darwin/OS X/iOS
Next by date:
Re: glibc+iconv

Updated Jun 25, 2012

Summary: Archive of the gentoo-embedded mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.