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.
>
>> # 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?
>
>> 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
>
>> 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.
>
>> 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.
Regards,
Marc
--
[EMAIL PROTECTED] mailing list
