Gentoo Archives: gentoo-embedded

From: Mike Frysinger <vapier@g.o>
To: gentoo-embedded@l.g.o
Subject: Re: [gentoo-embedded] glibc+iconv
Date: Fri, 14 Oct 2011 19:01:50
Message-Id: 201110141501.17986.vapier@gentoo.org
In Reply to: Re: [gentoo-embedded] glibc+iconv by Sergey Mironov
1 On Friday 14 October 2011 06:11:40 Sergey Mironov wrote:
2 > 2011/10/14 Mike Frysinger:
3 > > On Thursday 13 October 2011 19:30:14 Sergey Mironov wrote:
4 > >> 2011/10/14 Mike Frysinger:
5 > >> > On Thursday 13 October 2011 15:15:40 Sergey Mironov wrote:
6 > >> >> Hello. I have my arm-unknown-linux-gnueabi system which uses glibc
7 > >> >> and busybox. Recently I realised that iconv program doesn't exist in
8 > >> >> the tree. I've compared host's and target's glibc file lists and
9 > >> >> found that arm's version doesn't install anything to
10 > >> >> /usr/arm-unknown-linux-gnueabi/usr/bin. What can be the cause of
11 > >> >> this? Small C program shows that iconv_open function returns error
12 > >> >> code just like if there is no iconv at all. How shoud I make arm's
13 > >> >> iconv work?
14 > >> >
15 > >> > see glibc's files/eblits/src_compile.eblit:
16 > >> > is_crosscompile && sed -i '1ibuild-programs = no' config.make
17 > >> >
18 > >> > i imagine disabling that line will get you `iconv`
19 > >>
20 > >> Thanks, I will try it! Am I understand correctly that iconv itself
21 > >> (library, not program) is a part of glibc and it is not possible to
22 > >> exclude it during the build? So despite the lack of program I should
23 > >> still have fully functional library.
24 > >
25 > > your understanding is correct, however ........
26 > >
27 > > iconv() is part of glibc but it relies on all of the gconv shared libs
28 > > found in /usr/$CTARGET/usr/lib/gconv/ to do its actually work. which we
29 > > also incidentally delete when building the cross-compiler glibc (see
30 > > src_install.eblit and look for "gconv").
31 > >
32 > > you aren't the first person to find this behavior undesirable, and when i
33 > > implemented it, it was more of "let's save space on things i don't think
34 > > anyone will use". but if people are using it, then installing these
35 > > things probably makes sense.
36 >
37 > Well, maybe I really want something strange. I guess, people often
38 > install another, non-cross-compiled version of glibc on top of initial
39 > one. I've tried to do so, but found that cross-emerge complains about
40 > conflicts - it simply doesn't treat initial glibc as a package
41 > installed on target. I saw 2 ways - either edit package.provided and
42 > don't install new glibc or disable conflicts detection and overwrite
43 > some target's /lib* and /usr/lib/* files. I've chosen first way since
44 > I am afraid of getting a mess of two glibc's compiled with different
45 > tools. But how do you (or other people) act in this situation?
46
47 indeed, this is the current wonky behavior. i guess the thing to do would be
48 two fold:
49 - remove the disabling of tools/supplemental files so the cross-compiler
50 glibc has all the same files as sys-libs/glibc
51 - have crossdev automatically add a package.provided entry to the
52 /usr/$CTARGET/etc/ tree for sys-libs/glibc
53
54 > By the way, I also had to handcopy libstdc++.so from
55 > /usr/lib/gcc/$CTARGET to /usr/$CTARGET/lib to make C++ programs work.
56 > It is another thing which makes me thinking of installig full glibc on
57 > top of cross-one.
58
59 yes, the /usr/$CTARGET tree has no gcc files installed at all. in native
60 installs, we've got /etc/env.d/ which adds the internal gcc paths via LDPATH
61 to ld.so.conf, and then ldso at runtime finds libstdc++.so and friends. but
62 gcc is not installed at all in /usr/$CTARGET. in this case, you should be
63 able to emerge gcc into /usr/$CTARGET since none of the cross-compiler gcc
64 files should be in there ...
65 -mike

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-embedded] glibc+iconv Sergey Mironov <ierton@×××××.com>