[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] Some comments on gcc 4.3.2

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


Eero Tamminen wrote:

On Friday 10 October 2008, Miro Kropacek wrote:
Btw, this gnu stuff really rules. I spent a afternoon with compilation of
various linux packages (I took Linux From Scratch as the base). In 80% of
cases my work to get the newest stuff working was to set
--target=m68k-atari-mint or more directly, CC=m68k-atari-mint-gcc,
CFLAGS=-m68020-60 and here we go. Quite cool. The only bad thing on this
is it's without any packaging -- this is probably the most boring part of
whole process of releasing new packages -- take some RPM from Fedora for
example, "configure" it for FreeMiNT target, test it, fix, again test

One possibility would be to use something like:

It's intended for cross-compiling whole open source distributions without needing to adapt the sources or their packages for cross-compilation.
Currently it's tested to support Debian/Linux distribution cross-building
for ARM (Scratchbox itself works only on Linux), but I've heard of one
person who used it with MinGW toolchain to build Windows applications,
there was also one person using it for cross-building Slackware...

- Cross-building (configuring, compiling, running configure tests etc) seems
  to the compiled software like it were being built natively
- No need to modify sources/packaging for cross-compiling

Basic stuff that's needed:
- Toolchain for the target which is adapted for Scratchbox
- For the target platform either something like user-space Qemu or using
  small SBRSH client & daemon with NFS or SSH-FS to forward the test
  binaries that configure uses to sniff out the build environment into
  the (emulated or real) target environment.  The emulator or sbrsh are
  used as "interpreters" for the target binaries using Linux binfmt_misc
(- The packaging tools available either as target binaries or if more speed
  is needed, as "host binaries" modified to work in Scratchbox)

If you look into this, you'll also bump into newer SB2 project:

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.  (ptrace() would be another alternative for
doing similar things, but that's not used because ptrace() needs specific
support for each CPU architecture.  ELF is more generic solution.)

I was even played with the evil idea to make a distro just  based on
.tar.gz packages with some simple uninstall information (i.e. storing the
paths of installed files into some txt file) + maybe some unit way of
storing patches for source "packages". Or maybe directly adopt
Slackware-type packages. Who needs dependency checking in FreeMiNT world
anyway. We don't have shared libs so it's only about development packages
and every developer knows what it means "missing SDL.h file"... I know,
bad, bad guy :)

	- Eero