[Arm-netbook] EOMA68-IC1t successful board bring-up

[Luke Kenneth Casson Leighton]

On Thu, Oct 16, 2014 at 11:14 PM, Manuel A. Fernandez Montecelo
<manuel.montezelo at gmail.com> wrote:
> 2014-10-16 20:55 Luke Kenneth Casson Leighton:
>>
>> On Thu, Oct 16, 2014 at 6:37 PM, Manuel A. Fernandez Montecelo
>>>
>>>
>>> A difficult part that I see is if GCC cannot generate code for this
>>> architecture.  I think that many packages expect to be compiled in GCC,
>>> and if they are libraries or important pieces of infrastructure, they
>>> will block packages depending on them.  Even if it's a tiny percentage,
>>> there are more than 10K source packages in Debian nowadays, so it's not
>>> a minor task.
>>
>>
>> there's always a way round that: a package that "pretends" it is gcc
>> (i think it is something like "Provides")
>
>
> Yes, there are several ways to achieve that... but I meant that maybe some
> projects will only compile with GCC (or run properly if compiled with GCC),
> because they assume quirks in implementation, invalid syntax in language
> standards but valid in GCC, and things like that.  Like the reasons why
> Linux
> kernel does not compile with LLVM.  I think that many projects might have
> similar problems if the compiler is not GCC.

 well, we just have to suck it and see.  i think we will get a lot of
support from ICubeCorp (hopefully this will not overwhelm their
engineers) as they will *definitely* want to know when something
doesn't work... and fix it!

 bear in mind that this team have taken an amazingly brave step of
creating an entirely new architecture from scratch: they want to make
sure it succeeds, and is properly tested and reliable.  so reports to
them "compiler broke" are something they will pay attention to!

 that's one case.  the other - when bits of software break or don't
compile - that's ... *sigh* gonna be fun.  we'll just have to go
through them all one-by-one.

 i'm not a huge fan of maintaining patches by-hand.  i've used bitbake
before, to great effect.  its ability to store (and apply) patches at
*different phases* of a build... in a *reproducible and automated*
fashion is ... absolutely invaluable.

 there are even some patterns where configure is called, folliowed by
the autom4te cache being monkey-patched (or even replaced!) where
cross-compiling (particularly from 64-bit host of 32-bit targets) is
known (and guaranteed) to fail due to screw-ups by the developers or
just because it's simply not possible to do the right thing *ever*.

 bitbake's recipies comprise over fifteen years of highly-diverse
cross-compiling of tens of thousands of packages across _hundreds_ of
disparate systems from embedded with only 8mb of FLASH right the way
up to full desktop GNU/Linux distros that can be put onto standard x86
64-bit PCs.

 i think it would be a wise idea to hack that expertise into
submission and codify a DebianPorts system into it as a set of (mostly
new) recipes.

l.