On Thu, Oct 16, 2014 at 11:14 PM, Manuel A. Fernandez Montecelo manuel.montezelo@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.