[MeeGo-dev] Cross compilation tools (Was: MeeGo Reconstructed)
carsten at maemo.org
Fri Oct 21 13:46:50 UTC 2011
2011/10/21 Jeremiah Foster <jeremiah.foster at pelagicore.com>:
> On Fri, Oct 21, 2011 at 3:05 PM, Carsten Munk <carsten at maemo.org> wrote:
>> 2011/10/21 Lauri T. Aarnio <Lauri.T.Aarnio at nokia.com>:
>>> On Oct 19, 2011, at 2:44 PM, ext Carsten Munk wrote:
>>> That is in fact what we did for an experimental SB2-based SDK for Harmattan. There are even two perls, the ARM version and the x86 version (both are known as /usr/bin/perl.) They don't have to have similar configurations; the x86 side contains only selected tools and doesn't have to be updated so often.
>> Okay, so, let me elaborate - what I meant was - imagine this situation:
>> 1) Source package build-depends on, random example, perl-SSLeay, which
>> is a perl extension that's built with native code
> That is really a corner case. Most perl modules don't use XS (what you
> refer to as "native code") and the perl-SSLeay module has been a
> particular problem over the years because it has some pretty gnarly
> dependencies. You won't see this problem with most of the perl modules
> in MeeGo for example.
The case was generalized, using perl as an example - compiled code
also exists in python extensions, ruby extensions, or other things
people use for building within their packages these days. Generally:
compiled code extensions for anything that ought to be accelerated by
a X86 component as a use case
> But you have to recognize that people are not going to just use your
> packages, they're going to rebuild them. If they're not rebuilding
> your packages, then your particular software or image is not
> interesting for their particular problem. A reliance on a
> overly-complicated toolchain that makes the current process hard to
> reproduce and packages hard to rebuild on a new target or in a
> different build system. Everyone says "use our tool!" but in fact in
> open source you will find there are lots of tools, some of them as
> good as yours.
I'm not sure what you mean exactly, please elaborate. Besides that,
this discussion is actually about discussing cross compilation
approaches, alternatives, explaining each other's approaches :) For
some cases, multiarch might be good too.
With regards to 'hard to reproduce', two sides/things we've learnt from history:
1) Packages must not rely on being built inside a specific cross
This is what made Maemo packages so bloody hard to reproduce on top of
Debian/Ubuntu - they relied on things Scratchbox did. In the OBS
'cross' approach we try to be as close as possible to as how an ARM
machine would build the package.
2) MeeGo cross compilation was a nightmare to reproduce and copy to
other OBS'es and get working properly, due to source packages not
representing the needed contents / links between packages (like gcc to
obstag has helped this to some extent and now that we utilize fakeobs
& rsyncable source releases in Mer, anyone can set up a working setup
> === NOTE ===
> The information contained in this E-mail message is
> intended only for use of the individual or entity
> named above. If the reader of this message is not
> the intended recipient, or the employee or agent
> responsible to deliver it to the intended recipient,
> you are hereby notified that any dissemination,
> distribution or copying of this communication is
> strictly prohibited.
Someone should outlaw these signatures or at least create logic that
disables them from mailing lists..
More information about the MeeGo-dev