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?
> #!/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?
> # 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.
> 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} .
> 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.
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 :-)
> 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. :-)
hth,
Jason.
--
[EMAIL PROTECTED] mailing list
