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