1 |
Marc Blumentritt wrote: |
2 |
> Jason schrieb: |
3 |
>> If you haven't already, try this [1] out. Could you attach mm_emerge? |
4 |
[snip] |
5 |
>> [1] - http://www.gentoo.org/proj/en/base/embedded/cross-development.xml |
6 |
> |
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 |
|
14 |
> #!/bin/bash |
15 |
> |
16 |
> check_bind || bind_dirs |
17 |
|
18 |
This looks dangerous (speaking from experience, I overwrote my host's |
19 |
64bit LSB x86 glibc files with 32bit ARM MSB uclibc once. Once. ;-) |
20 |
No, I didn't have to reinstall) Which dir's are you binding? |
21 |
|
22 |
> # source and export vars |
23 |
> . /mediamachine/tools/vars |
24 |
> export PORTAGE_CONFIGROOT ROOT |
25 |
|
26 |
If you're in chroot, this should be fine. If not, I'd be cautious with |
27 |
this. It would be better (especially since it's in a script) to say: |
28 |
|
29 |
PORTAGE_CONFIGROOT=${SYSROOT} ROOT=${TGTROOT} emerge $* |
30 |
|
31 |
By exporting those vars, they'll be set after the script finishes. So a |
32 |
later 'emerge foo' in the same terminal would have unanticipated results. |
33 |
|
34 |
> cp /etc/passwd /tmp |
35 |
> cp /etc/shadow /tmp |
36 |
> cp /etc/group /tmp |
37 |
> |
38 |
> # run emerge |
39 |
> emerge $* |
40 |
> |
41 |
> echo "****** passwd diff *******" |
42 |
> diff /tmp/passwd /etc/passwd |
43 |
> mv -f /tmp/passwd /etc/passwd |
44 |
> echo "###### shadow diff ######" |
45 |
> diff /tmp/shadow /etc/shadow |
46 |
> mv -f /tmp/shadow /etc/shadow |
47 |
> echo "++++++ group diff +++++++" |
48 |
> diff /tmp/group /etc/group |
49 |
> mv -f /tmp/group /etc/group |
50 |
|
51 |
This shouldn't be necessary. When portage adds the pkg to your build |
52 |
system ( / ), it will update these files as it is supposed to. That |
53 |
should be fine. When you then install the pkg to $ROOT (assuming it is |
54 |
an RDEPEND or pkg you want), it should make the necessary changes to |
55 |
${ROOT}/etc/{passwd,shadow,group} . |
56 |
|
57 |
> With bind_dirs I bind some dirs, which I need for building, but not for |
58 |
> running my embedded system. The passwd/shadow/group stuff is there to |
59 |
> show me changes in these files, because they are made to my build system |
60 |
> and not to the embedded system in ROOT. /mediamachine/tools/vars |
61 |
> contains the definition of ROOT and PORTAGE_CONFIGROOT . |
62 |
|
63 |
I think the concept you may be missing here is that portage needs three |
64 |
locations, not two. Portage is going to PORTAGE_CONFIGROOT for portage |
65 |
config stuff (USE flags, package.keywords, and so on), it installs the |
66 |
finished pkg to ROOT, but it needs to go somewhere to find files to |
67 |
build against. Dependencies have to come from somewhere. In your case, |
68 |
this is '/'. This is correct behavior on the part of portage because we |
69 |
don't want to leave a bunch of non-runtime pkgs in ROOT. |
70 |
|
71 |
So, if it doesn't see zlib.h in /usr/include/, it's going to try to |
72 |
install sys-libs/zlib in '/'. If sys-libs/zlib is also an RDEPEND for |
73 |
your pkg, it will need to be installed to $ROOT also. Most likely you |
74 |
only need the shared libraries in ROOT, eg 'libz.so*'. You should be |
75 |
able to delete the includes and static libs from $ROOT (*.h,*.a,*.la) |
76 |
since those are only used for building. At least, that works for me :-) |
77 |
|
78 |
> Concerning [1], if I would use cross compilation with ROOT and |
79 |
> PORTAGE_CONFIGROOT, would the same happen there? I mean, would some |
80 |
> packages be installed in the build system? That would be really bad, |
81 |
> wouldn't it? |
82 |
|
83 |
Cross-compiling is different because those build dependencies I |
84 |
mentioned above have to be installed in $SYSROOT which equals |
85 |
PORTAGE_CONFIGROOT. This is necessary because the cross-compiler can't |
86 |
read any of the files in '/', they're for the wrong target architecture. |
87 |
And, as you mentioned, the host system can't understand anything built |
88 |
for the target arch. Yes, that is very bad. See my comment above about |
89 |
ARM uclibc being written over the host glibc. :-) |
90 |
|
91 |
hth, |
92 |
|
93 |
Jason. |
94 |
-- |
95 |
gentoo-embedded@g.o mailing list |