1 |
Jason schrieb: |
2 |
> Marc Blumentritt wrote: |
3 |
>> Jason schrieb: |
4 |
>>> If you haven't already, try this [1] out. Could you attach mm_emerge? |
5 |
> [snip] |
6 |
>>> [1] - http://www.gentoo.org/proj/en/base/embedded/cross-development.xml |
7 |
>> I was using [1] to write mm_emerge: |
8 |
>> |
9 |
>> (build) hive / # cat /mediamachine/tools/mm_emerge |
10 |
> |
11 |
> Does '(build)' imply you are chrooted into your build environment? If |
12 |
> so, why? |
13 |
Because I'm working in a uclibc-stage3 setup. |
14 |
|
15 |
> |
16 |
>> #!/bin/bash |
17 |
>> |
18 |
>> check_bind || bind_dirs |
19 |
> |
20 |
> This looks dangerous (speaking from experience, I overwrote my host's |
21 |
> 64bit LSB x86 glibc files with 32bit ARM MSB uclibc once. Once. ;-) |
22 |
> No, I didn't have to reinstall) Which dir's are you binding? |
23 |
|
24 |
I started with empty dirs (e.g. for $ROOT/var/db) and bind another empty |
25 |
dir (e.g. $BIND_DIRS/var/db) to it. After emerging I have everything, |
26 |
which is not needed for a running system, under $BIND_DIRS and not in |
27 |
$ROOT. The only things I bind from my stage3 to my embedded system, are |
28 |
/dev, /proc, and kernel source. Therefore I do not mix my envireonments. |
29 |
|
30 |
> |
31 |
>> # source and export vars |
32 |
>> . /mediamachine/tools/vars |
33 |
>> export PORTAGE_CONFIGROOT ROOT |
34 |
> |
35 |
> If you're in chroot, this should be fine. If not, I'd be cautious with |
36 |
> this. It would be better (especially since it's in a script) to say: |
37 |
> |
38 |
> PORTAGE_CONFIGROOT=${SYSROOT} ROOT=${TGTROOT} emerge $* |
39 |
> |
40 |
> By exporting those vars, they'll be set after the script finishes. So a |
41 |
> later 'emerge foo' in the same terminal would have unanticipated results. |
42 |
|
43 |
Not in my case!? |
44 |
|
45 |
(build) hive mediamachine # mm_emerge -pv dropbear |
46 |
|
47 |
These are the packages that would be merged, in order: |
48 |
|
49 |
Calculating dependencies... done! |
50 |
[ebuild R ] net-misc/dropbear-0.49 to /mediamachine/devroot/ |
51 |
USE="minimal -multicall -pam -savedconfig -static -zlib" 1,724 kB |
52 |
|
53 |
Total: 1 package (1 reinstall), Size of downloads: 1,724 kB |
54 |
****** passwd diff ******* |
55 |
###### shadow diff ###### |
56 |
++++++ group diff +++++++ |
57 |
(build) hive mediamachine # echo $ROOT |
58 |
|
59 |
(build) hive mediamachine # |
60 |
|
61 |
Or did I miss something? |
62 |
|
63 |
> |
64 |
>> cp /etc/passwd /tmp |
65 |
>> cp /etc/shadow /tmp |
66 |
>> cp /etc/group /tmp |
67 |
>> |
68 |
>> # run emerge |
69 |
>> emerge $* |
70 |
>> |
71 |
>> echo "****** passwd diff *******" |
72 |
>> diff /tmp/passwd /etc/passwd |
73 |
>> mv -f /tmp/passwd /etc/passwd |
74 |
>> echo "###### shadow diff ######" |
75 |
>> diff /tmp/shadow /etc/shadow |
76 |
>> mv -f /tmp/shadow /etc/shadow |
77 |
>> echo "++++++ group diff +++++++" |
78 |
>> diff /tmp/group /etc/group |
79 |
>> mv -f /tmp/group /etc/group |
80 |
> |
81 |
> This shouldn't be necessary. When portage adds the pkg to your build |
82 |
> system ( / ), it will update these files as it is supposed to. That |
83 |
> should be fine. When you then install the pkg to $ROOT (assuming it is |
84 |
> an RDEPEND or pkg you want), it should make the necessary changes to |
85 |
> ${ROOT}/etc/{passwd,shadow,group} . |
86 |
|
87 |
Yes, should. When I directly install in $ROOT without building first a |
88 |
bin pkg, portage does not change any of these files, but does change the |
89 |
files of my build system. There is an open bug about this: |
90 |
|
91 |
http://bugs.gentoo.org/show_bug.cgi?id=53269 |
92 |
|
93 |
> |
94 |
>> With bind_dirs I bind some dirs, which I need for building, but not for |
95 |
>> running my embedded system. The passwd/shadow/group stuff is there to |
96 |
>> show me changes in these files, because they are made to my build system |
97 |
>> and not to the embedded system in ROOT. /mediamachine/tools/vars |
98 |
>> contains the definition of ROOT and PORTAGE_CONFIGROOT . |
99 |
> |
100 |
> I think the concept you may be missing here is that portage needs three |
101 |
> locations, not two. Portage is going to PORTAGE_CONFIGROOT for portage |
102 |
> config stuff (USE flags, package.keywords, and so on), it installs the |
103 |
> finished pkg to ROOT, but it needs to go somewhere to find files to |
104 |
> build against. Dependencies have to come from somewhere. In your case, |
105 |
> this is '/'. This is correct behavior on the part of portage because we |
106 |
> don't want to leave a bunch of non-runtime pkgs in ROOT. |
107 |
|
108 |
Your are right. I did not know this. Thanks for clarification. |
109 |
|
110 |
> |
111 |
> So, if it doesn't see zlib.h in /usr/include/, it's going to try to |
112 |
> install sys-libs/zlib in '/'. If sys-libs/zlib is also an RDEPEND for |
113 |
> your pkg, it will need to be installed to $ROOT also. Most likely you |
114 |
> only need the shared libraries in ROOT, eg 'libz.so*'. You should be |
115 |
> able to delete the includes and static libs from $ROOT (*.h,*.a,*.la) |
116 |
> since those are only used for building. At least, that works for me :-) |
117 |
|
118 |
I will try this and clean up my system. I will see, if this works. |
119 |
|
120 |
> |
121 |
>> Concerning [1], if I would use cross compilation with ROOT and |
122 |
>> PORTAGE_CONFIGROOT, would the same happen there? I mean, would some |
123 |
>> packages be installed in the build system? That would be really bad, |
124 |
>> wouldn't it? |
125 |
> |
126 |
> Cross-compiling is different because those build dependencies I |
127 |
> mentioned above have to be installed in $SYSROOT which equals |
128 |
> PORTAGE_CONFIGROOT. This is necessary because the cross-compiler can't |
129 |
> read any of the files in '/', they're for the wrong target architecture. |
130 |
> And, as you mentioned, the host system can't understand anything built |
131 |
> for the target arch. Yes, that is very bad. See my comment above about |
132 |
> ARM uclibc being written over the host glibc. :-) |
133 |
|
134 |
OK, thanks again for clarification. |
135 |
|
136 |
Regards, |
137 |
Marc |
138 |
|
139 |
-- |
140 |
gentoo-embedded@g.o mailing list |