Marc Blumentritt wrote:
> Jason schrieb:
>> Marc Blumentritt wrote:
>>> Jason schrieb:
>>>> If you haven't already, try this [1] out. Could you attach mm_emerge?
>> [snip]
>>>> [1] - http://www.gentoo.org/proj/en/base/embedded/cross-development.xml
>>> I was using [1] to write mm_emerge:
>>>
>>> (build) hive / # cat /mediamachine/tools/mm_emerge
>> Does '(build)' imply you are chrooted into your build environment? If
>> so, why?
> Because I'm working in a uclibc-stage3 setup.
>
>>> #!/bin/bash
>>>
>>> check_bind || bind_dirs
>> This looks dangerous (speaking from experience, I overwrote my host's
>> 64bit LSB x86 glibc files with 32bit ARM MSB uclibc once. Once. ;-)
>> No, I didn't have to reinstall) Which dir's are you binding?
>
> I started with empty dirs (e.g. for $ROOT/var/db) and bind another empty
> dir (e.g. $BIND_DIRS/var/db) to it. After emerging I have everything,
> which is not needed for a running system, under $BIND_DIRS and not in
> $ROOT. The only things I bind from my stage3 to my embedded system, are
> /dev, /proc, and kernel source. Therefore I do not mix my envireonments.
Okay, so you're using bind so you don't have to trim the final image.
Neat. Personally, I 'cp -ax ${TGTROOT}/* /tmp/img_dir/', then my script
trims out var/db, etc/portage, usr/{src,include}, and so on. I was also
considering moving to 'rsync -FF ...', but I haven't decided yet. It
seems more adaptable, but it litters the fs with a lot of .rsync-filter
files (they are excluded from the transfer by the second 'F').
>>> # source and export vars
>>> . /mediamachine/tools/vars
>>> export PORTAGE_CONFIGROOT ROOT
>> If you're in chroot, this should be fine. If not, I'd be cautious with
>> this. It would be better (especially since it's in a script) to say:
>>
>> PORTAGE_CONFIGROOT=${SYSROOT} ROOT=${TGTROOT} emerge $*
>>
>> By exporting those vars, they'll be set after the script finishes. So a
>> later 'emerge foo' in the same terminal would have unanticipated results.
>
> Not in my case!?
>
> (build) hive mediamachine # mm_emerge -pv dropbear
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
> [ebuild R ] net-misc/dropbear-0.49 to /mediamachine/devroot/
> USE="minimal -multicall -pam -savedconfig -static -zlib" 1,724 kB
>
> Total: 1 package (1 reinstall), Size of downloads: 1,724 kB
> ****** passwd diff *******
> ###### shadow diff ######
> ++++++ group diff +++++++
> (build) hive mediamachine # echo $ROOT
>
> (build) hive mediamachine #
>
> Or did I miss something?
my mistake. I confused sourcing the bash script with executing it.
Good catch. :-)
>>> cp /etc/passwd /tmp
>>> cp /etc/shadow /tmp
>>> cp /etc/group /tmp
>>>
>>> # run emerge
>>> emerge $*
>>>
>>> echo "****** passwd diff *******"
>>> diff /tmp/passwd /etc/passwd
>>> mv -f /tmp/passwd /etc/passwd
>>> echo "###### shadow diff ######"
>>> diff /tmp/shadow /etc/shadow
>>> mv -f /tmp/shadow /etc/shadow
>>> echo "++++++ group diff +++++++"
>>> diff /tmp/group /etc/group
>>> mv -f /tmp/group /etc/group
>> This shouldn't be necessary. When portage adds the pkg to your build
>> system ( / ), it will update these files as it is supposed to. That
>> should be fine. When you then install the pkg to $ROOT (assuming it is
>> an RDEPEND or pkg you want), it should make the necessary changes to
>> ${ROOT}/etc/{passwd,shadow,group} .
>
> Yes, should. When I directly install in $ROOT without building first a
> bin pkg, portage does not change any of these files, but does change the
> files of my build system. There is an open bug about this:
>
> http://bugs.gentoo.org/show_bug.cgi?id=53269
Wow, that's an old one. I haven't seen this behavior when
cross-compiling. I also haven't been looking for it either. I'll keep
an eye out.
>>> With bind_dirs I bind some dirs, which I need for building, but not for
>>> running my embedded system. The passwd/shadow/group stuff is there to
>>> show me changes in these files, because they are made to my build system
>>> and not to the embedded system in ROOT. /mediamachine/tools/vars
>>> contains the definition of ROOT and PORTAGE_CONFIGROOT .
>>
>> I think the concept you may be missing here is that portage needs three
>> locations, not two. Portage is going to PORTAGE_CONFIGROOT for portage
>> config stuff (USE flags, package.keywords, and so on), it installs the
>> finished pkg to ROOT, but it needs to go somewhere to find files to
>> build against. Dependencies have to come from somewhere. In your case,
>> this is '/'. This is correct behavior on the part of portage because we
>> don't want to leave a bunch of non-runtime pkgs in ROOT.
>
> Your are right. I did not know this. Thanks for clarification.
>
>> So, if it doesn't see zlib.h in /usr/include/, it's going to try to
>> install sys-libs/zlib in '/'. If sys-libs/zlib is also an RDEPEND for
>> your pkg, it will need to be installed to $ROOT also. Most likely you
>> only need the shared libraries in ROOT, eg 'libz.so*'. You should be
>> able to delete the includes and static libs from $ROOT (*.h,*.a,*.la)
>> since those are only used for building. At least, that works for me :-)
>
> I will try this and clean up my system. I will see, if this works.
You should be able to use your BINDDIR trick on usr/{include,src},
however, static libs are in the same directories as shared libs. I
usually do a:
find ${TGTROOT}/ -name "*.a" -print >>${file_list}
find ${TGTROOT}/ -name "*.la" -print >>${file_list}
You could also replace '-print' with '-exec rm -f {} ';'' but I like to
print out the list first, and hit a key to confirm.
>>> Concerning [1], if I would use cross compilation with ROOT and
>>> PORTAGE_CONFIGROOT, would the same happen there? I mean, would some
>>> packages be installed in the build system? That would be really bad,
>>> wouldn't it?
>>
>> Cross-compiling is different because those build dependencies I
>> mentioned above have to be installed in $SYSROOT which equals
>> PORTAGE_CONFIGROOT. This is necessary because the cross-compiler can't
>> read any of the files in '/', they're for the wrong target architecture.
>> And, as you mentioned, the host system can't understand anything built
>> for the target arch. Yes, that is very bad. See my comment above about
>> ARM uclibc being written over the host glibc. :-)
>
> OK, thanks again for clarification.
Glad I could help. Keep in mind, I'm still learning all this myself. ;-)
thx,
Jason.
--
gentoo-embedded@g.o mailing list
|
