Re: [MiNT] distro cross-building

[Eero Tamminen <oak@helsinkinet.fi>]

Hi,

On Saturday 11 October 2008, Mark Duckworth wrote:
> This makes a lot of sense.  I used scratchbox to build the arm toolchain
> for my pool controller system.  It's pretty easy to use and we'd
> maintain everything on modern hardware.  It may be a lot easier to
> consider the falcon an embedded platform and follow those ideals.....
> But then again we lose RPM and such.

Scratchbox is not tied to any specific packaging system.  Debian support
is just a separate "devkit" which you can install on top of it. Somebody
could do a similar "devkit" also for RPM package management.  Or one could 
just use native binaries which Scratchbox automatically runs through
the emulator[1].  Devkit is just a ready-made set of host-tools that can be
installed inside Scratchbox to speed up use of the given tools.

[1] This is achieved with the Linux binfmt_misc feature where one specifies
that given binaries are "interpreted" with an emulator and that emulator
then allows running foreign binaries like they were native programs (like
user-space qemu does).  Or if there's no such emulator, sbrsh client can be
used instead to run the (configure test etc) binaries on a real machine that
support NFS mounting and has sbrshd daemon running on it.


> They all use debian ipkg - again that might make a LOT more sense than
>using rpm.  Ipkg is certainly a lot easier.

Ipkg is not really a package manager, more of a just package downloader &
installer as it doesn't handle conflicts, distro upgrades etc properly like
real package management systems do.


> I've had a sharp zaurus for a long time so I have a lot of experience with
> the linux embedded stuff.  I would probably be able to help out a lot with
> such an endeavor. 

Then there are some source based "distributions".  Like Gentoo, BSD ports
(on which e.g. Gnome Garnome and the similar KDE thing are based on that are
used for building their source snapshots) and Open Embedded.  EO builds are
managed by some Python based tools which uses "recipe" for each source to
cross-build it.  OE "recipes" contains settings for pre-seeding configure
for corrent target etc.  

But I guess source based distros are not that interesting for MiNT because 
native builds take so long...


> Eero Tamminen wrote:
> > If you look into this, you'll also bump into newer SB2 project:
> > 	http://freedesktop.org/wiki/Software/sbox2/Maemo
> >
> > It has smaller scope and can therefore be a bit more manageable. 
> > However, it uses LD_PRELOAD to do its stuff, so it works only on
> > targets using dynamically linked ELF binaries.

Sorry, the ELF support is needed only from the host system.  From the target
system software ELF support is needed only if one wants to compile also x86
versions of it, but in the MiNT case that's not relevant (emulator or sbrsh
is used for the binaries that have different CPU architecture than the host,
so LD_PRELOAD is not relevant for that).

I.e. Linux based SB2 cross-build environment for m68k/MiNT could be also
feasible and because SB2 is much smaller than SB1 (it doesn't a set of 
host-tools that are specially compiled for it) it could be more manageable.
AFAIK SB2 may change to be (much) more tied to Debian though, so if somebody
wants it to support also RPM, I think this is about last moment to start
looking into contributing patches to SB2 for that... :-)

(I think SB2 is going to replace SB1 at some point because host tools
maintenance requires much less effort with it, so it might make more sense
to try that first.  I know about both SB1 & SB2 and may be able to answer
questions about them if somebody starts looking into m68k/MiNT
cross-building with either of them.)


	- Eero