[Sugar-devel] The ARM is near
Tomeu Vizoso
tomeu at sugarlabs.org
Fri Aug 28 04:13:24 EDT 2009
On Fri, Aug 28, 2009 at 04:58, Benjamin M.
Schwartz<bmschwar at fas.harvard.edu> wrote:
> Bobby Powers wrote:
>> I think having something like:
>>
>> example.activity
>> |-arch/
>> |-arch/x86/
>> |-arch/x86/bin/
>> |-arch/x86/lib/
>> |-arch/armel/
>> ...
>>
>> could work. Sugar could set an environmental variable ARCH to the
>> relevant value, and we could have a reference activity_startup.sh
>> which adds the correct lib path to LD_LIBRARY_PATH and launches the
>> appropriate executable (or maybe a flag in activty.info which has
>> sugar do this). This is still somewhat kludgy, but I'm not sure of a
>> better way.
>
> Which solution we should choose is a technical discussion that deserves
> its own thread. I'm personally not enthusiastic about the "fat packages"
> approach, in which binaries for many architectures are included in one .xo
> bundle, because:
>
> 1. It wastes space, by carrying around duplicate copies. This gets even
> worse for >2 architectures, and even 32-bit and 64-bit x86 might need to
> be treated as separate architectures.
> 2. It's not future-proof. Packages that work on ARM and x86 will be
> broken again if we try to support MIPS (like the Lemote laptops, Free and
> perfect for Sugar), or maybe even Sparc or Power (massively SMT chips,
> perfect for LTSP).
> 3. It won't happen. Cross-compiling libraries is tremendously difficult,
> so Activity developers won't do it. They'll just get it working on their
> platform and ship it.
> 4. It's unreliable. There is no good way to produce binaries that are
> guaranteed to work on both 32-bit x86 Fedora 9 and 32-bit x86 Fedora 10.
> Changes between versions can break binary compatibility. Between
> different distros it's even worse. The Pippy activity recently
> experienced exactly this problem due to the included Box2D binary library.
I don't think we should aim for the perfect solution here, rather for
what can work best for our restricted use cases. Otherwise we run the
risk of not moving forward because we take a much bigger challenge we
can actually overcome.
If fat binaries are not desired, which alternatives do we have?
Regards,
Tomeu
> --Ben
>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
--
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
More information about the Sugar-devel
mailing list