porting binaries to target NFS Root Filesystem

Dear all,

I have some questions regarding the transferring of binaries
compiled using 
ScratchBox.
1) In order to test the complied binaries on the target
board, all i need to 
do is copy the files from the ScratchBox Target directory to
the respective 
directories in my RFS of my target board? Do i need change
any links, 
whatsoever?

2) Is there anyway to direct Scratchbox to place all the
complied binaries 
directly to my target board RFS which is mounted on the host
system using 
NFS?

Thanks for any help provided

Regards,
Kelvin

____________________________________________________________
_____
Find singles online in your area with MSN Dating and
Match.com! 
h
ttp://cp.intl.match.com/eng/msn/msnsg/wbc/wbc.html

_______________________________________________
Scratchbox-users mailing list
Scratchbox-userslists.scratchbox.org
http://lists.scratchbox.org/cgi-bin/mailman
/listinfo/scratchbox-users

2007/1/1, Kelvin Xu <kyoxuhotmail.com>:
> Dear all,
>
> I have some questions regarding the transferring of
binaries compiled using
> ScratchBox.
> 1) In order to test the complied binaries on the target
board, all i need to
> do is copy the files from the ScratchBox Target
directory to the respective
> directories in my RFS of my target board? Do i need
change any links,
> whatsoever?

No, the target directory is ready to go as-is[1]. The only
things that
have differences (apart from purely virtual filesystems like
proc and
sysfs) are /tmp and /dev. Both are mounted from the host
computer.
Now, tmp is not a broblem (as you can't rely on it anyway),
but dev
has some implications.

> 2) Is there anyway to direct Scratchbox to place all
the complied binaries
> directly to my target board RFS which is mounted on the
host system using
> NFS?

A useful trick is to do that the other way (mount the sb
target
directory directly to the device), but as said, this needs
targets/target_name/dev to be populated by hand. I guess you
could
mount the RFS over the scratchbox target dir, but it will
also mean
that anything installed goes there...

If the packages are nice and support setting DESTDIR during
install,
one might also do this by mounting the RFS somewhere
accessible inside
the sb target and do a 'make install DESTDIR=/tmp/foo', but
this has
the same problem as above.

The usual way to solve it is to use a script that generates
the rootfs
(ie. strips the cruft away).

-- 
Kalle Vahlman, zuhiki.fi
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi
_______________________________________________
Scratchbox-users mailing list
Scratchbox-userslists.scratchbox.org
http://lists.scratchbox.org/cgi-bin/mailman
/listinfo/scratchbox-users

Hi,

What you meant is to use the scratchbox directory as the RFS
of the target 
directly using NFS? And then populate the dev directory and
copying over 
necessary files for the kernel to work properly such as
busybox, kernel 
modules and headers?

Regards,
Kelvin


>From: "Kalle Vahlman" <kalle.vahlmangmail.com>
>Reply-To: zuhiki.fi, scratchbox-userslists.scratchbox.org
>To: scratchbox-userslists.scratchbox.org
>Subject: Re: [Scratchbox-users] porting binaries to
target NFS Root 
>Filesystem
>Date: Mon, 1 Jan 2007 23:33:35 +0200
>
>2007/1/1, Kelvin Xu <kyoxuhotmail.com>:
>>Dear all,
>>
>>I have some questions regarding the transferring of
binaries compiled 
>>using
>>ScratchBox.
>>1) In order to test the complied binaries on the
target board, all i need 
>>to
>>do is copy the files from the ScratchBox Target
directory to the 
>>respective
>>directories in my RFS of my target board? Do i need
change any links,
>>whatsoever?
>
>No, the target directory is ready to go as-is[1]. The
only things that
>have differences (apart from purely virtual filesystems
like proc and
>sysfs) are /tmp and /dev. Both are mounted from the host
computer.
>Now, tmp is not a broblem (as you can't rely on it
anyway), but dev
>has some implications.
>
>>2) Is there anyway to direct Scratchbox to place all
the complied binaries
>>directly to my target board RFS which is mounted on
the host system using
>>NFS?
>
>A useful trick is to do that the other way (mount the sb
target
>directory directly to the device), but as said, this
needs
>targets/target_name/dev to be populated by hand. I guess
you could
>mount the RFS over the scratchbox target dir, but it
will also mean
>that anything installed goes there...
>
>If the packages are nice and support setting DESTDIR
during install,
>one might also do this by mounting the RFS somewhere
accessible inside
>the sb target and do a 'make install DESTDIR=/tmp/foo',
but this has
>the same problem as above.
>
>The usual way to solve it is to use a script that
generates the rootfs
>(ie. strips the cruft away).
>
>--
>Kalle Vahlman, zuhiki.fi
>Powered by http://movial.fi
>Interesting stuff at http://syslog.movial.fi
>_______________________________________________
>Scratchbox-users mailing list
>Scratchbox-userslists.scratchbox.org
>http://lists.scratchbox.org/cgi-bin/mailman
/listinfo/scratchbox-users

____________________________________________________________
_____
Find singles online in your area with MSN Dating and
Match.com! 
h
ttp://cp.intl.match.com/eng/msn/msnsg/wbc/wbc.html

_______________________________________________
Scratchbox-users mailing list
Scratchbox-userslists.scratchbox.org
http://lists.scratchbox.org/cgi-bin/mailman
/listinfo/scratchbox-users

2007/1/2, Kelvin Xu <kyoxuhotmail.com>:
> Hi,
>
> What you meant is to use the scratchbox directory as
the RFS of the target
> directly using NFS?

The scratchbox _target_ directory
(/scratchbox/users/foo/targets/bar
outside SB), but yes, we use that a lot since it's faster
(as in time
from make install to running, probably not otherwise  than
flashing
or simply copying stuff. There is some tweaking with the
access rights
of files, as inside SB you can't be root, and if the NFS
mount has
root_squash on it will not create root-owned files really.

> And then populate the dev directory and copying over
> necessary files for the kernel to work properly such as
busybox, kernel
> modules and headers?

Well as the target directory is basically a chroot
environment, it
doesn't require much work (depending on your setup of
course). So
busybox and friends should be already in place. I'm not 100%
sure but
I guess kernel modules should be too, at least those built
as a part
of the kernel. If you build a "standalone" module,
it might pick up
the host system kernel version as the install location...

One more dir that I forgot to mention is /etc. Again, I'm
not into the
details but basically you just need to be sure to edit stuff
under
/etc from /targets/bar/etc, not just /etc inside scratchbox.
There is
some magic there, but I'll leave it to the SB guys to tell
you what ;)

This is true for /dev too, be careful not to do anything to
/dev
inside SB, as that is the host machines /dev!

-- 
Kalle Vahlman, zuhiki.fi
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi
_______________________________________________
Scratchbox-users mailing list
Scratchbox-userslists.scratchbox.org
http://lists.scratchbox.org/cgi-bin/mailman
/listinfo/scratchbox-users