Re: ARMv4-support in armel/squeeze?
+++ Luke Kenneth Casson Leighton [2010-12-20 11:10 +0000]:
> On Mon, Dec 20, 2010 at 12:08 AM, Wookey <wookey@wookware.org> wrote:
> > +++ Luke Kenneth Casson Leighton [2010-12-19 21:04 +0000]:
> >
> >> weelll... how about creating an easy means for anybody to create
> >> their _own_ debootstrap'd cross-compiled starting point, based on
> >> _their_ decisions and requirements, and debian can host the most
> >> popular ones?
> >
> > I quite agree (and have done for years), and am actually working on it
> > at the moment.
>
> fantastic!
>
> ... i can't help say it though: you are no doubt aware that this very
> much looks like "wheel-duplication"; that openembedded's build system
> has all this sorted for absolutely years? (there's also portage but
> it's nothing like as well-utilised for both cross and native compiling
> as openembedded).
>
> so i'm curious: is there any particular reason why, instead of
> turning an existing tool which does 95% of the work with 10% extra
> effort to create the tool, a complete from-scratch
> debootstrap-cross-compiler was started instead?
Essentially because I think it'll work better if it's done with Debian
infrastructure and tools than if it's done with OE tools. The OE tools
depend on the OE packagaing ('recipies') and that's not the same as
the Debian packaging.
You could use OE receipies to patch Debian packages in order to make
them cross-build and generate staging packages and generally be
buildable using bitbake. And that would also provide a sequencing
tool. This would probably work reasonably well, and I've even
considered trying it in the past. It remains an interesting idea and
if you want to try it for real I'd be interested to know how it goes.
However the recipies produced would sit outside the packages
and thus would immediately start to bitrot, so next time someone wants
to do a bootstrap they'd proabbly need to do a lot of updating of
recipies to current packages. And some of the patches in there would
be pretty hacky because the packages don't contain the right metadata
and don't have good mechanisms for making the necessary cross-build
and bootastrapping changes.
I think it's better to work out proper Debian-packaging-friendly
mechanism (or use existing ones where there is one) to do what is
needed, and (having shown that this stuff works and is useful)
enshrine it in policy. This is much more robust in the long term.
This is almost all about metadata and packaging, not about special
build tools.
Now - I could be wrong, and perhaps this can't be made to work well
without all the magic 'pre-configure' and 'post-staging' sort of
tweaking that goes on in OE. But I haven't yet seen reasons to conclude
that. In practice this question will only be determined by trying it.
> so - the system you're creating: will it be possible, right at the
> beginning, to specify the compiler flags and options required?
It doesn't address that issue directly. The way you set the default
compiler options is to build a new 'flavoured' toolchain with the
correct defaults. Personally I think that's really ugly, but it seems
to be the only way that works reliably, and due to the way gcc builds
itself to generate libgcc, there are real problems with building a
toolchain that can be given loads of different build options.
Wrappers can also work (as used in pentium-builder and apt-build).
But, as Joey says here:
http://joey.kitenet.net/blog/entry/ten_years_of_free_software_--_part_8_pentium-builder/
it would be better to fix the underlying packaging issues which
prevent default options from propogating properly. This would require
a load of packages fixing and probably some policy adressing it.
And wrappers can only cover a small set of possible optimisations
unless you can build lots of libgcc variants. (See
http://wiki.debian.org/Multiarch/Spec for useful elaboration)
> the reason i ask is that i have encountered a 400mhz ARM926EJS system
> which has ... get this: 800mhz DDR2 RAM! (ok, 400mhz bus,
> double-data-rate). the memory is therefore as fast as the CPU (!) and
> so any logic which says "thumb instructions are faster" is completely
> out the window. i would therefore like to do a complete, total
> rebuild of the ARM926 debian packages.... with thumb *disabled* but
> thumb interoperability enabled and ... well anything else i can think
> of that will be deliberately wildly different from "standard" debian
> just to get the point across :)
>
> so - will it be possible to do a total rebuild (requiring about 10
> minutes of reading documentation to create one config file, one
> command line) of debootstrap and beyond, with "ARM926EJS with thumb
> disabled"?
This can certainly be done with a flavoured cross-toolchain (currently
available in Ubuntu, but not Debian). Some investigation into what we
can achieve with tools like apt-build/pentium builder in a cross
context would also be very useful.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: