From mint-bounce@lists.fishpool.fi Fri Oct 10 18:06:07 2008 Message-ID: <48EFD0D0.3040707@atari-source.org> Date: Fri, 10 Oct 2008 18:01:52 -0400 From: Mark Duckworth User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Eero Tamminen CC: mint@lists.fishpool.fi, Miro Kropacek , Patrice Mandin , mint Subject: Re: [MiNT] Some comments on gcc 4.3.2 References: <20081010123824.03e0a925.mandin.patrice@orange.fr> <200810110019.01757.oak@helsinkinet.fi> In-Reply-To: <200810110019.01757.oak@helsinkinet.fi> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: mduckworth@atari-source.org Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: 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. Thanks, Mark Eero Tamminen wrote: > Hi, > > 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 >> etc... >> > > One possibility would be to use something like: > http://www.scratchbox.org/ > > 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... > > Advantages: > - 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 > feature > (- 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: > 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. (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 > > >