6 décembre 2016 15:00 "Ed Robbins" <dmarc-noreply@xxxxxxxxxxxxx> a écrit:
I'm not a haiku dev, but seeing you mentioning dropping x86 for R2... surely
it makes sense to keep
the code 32-bit compatible?
gcc will not drop support for x86 any time soon. So in the plan where R2 is
x86_64 only, it should
still be possible to build an x86 gcc5 R2 haiku, unless someone intentionally
breaks something,
right? Is that breakage foreseen somewhere?
On 6 December 2016 at 08:05, Stephan Aßmus <superstippi@xxxxxx> wrote:
Hi,
Am 6. Dezember 2016 07:19:46 schrieb Adrien Destugues
<pulkomandy@xxxxxxxxxxxxx>:
On Tue, Dec 06, 2016 at 12:22:02AM +0100, David Given wrote:
On 05/12/16 23:21, kallisti5 wrote:
[...]
Then simply run the 32-bit gcc2h that has gcc5 as a secondary
architecture.
Not sure what the pain point is here... we're already catering to 32-bit
machines with these R1 release plans :-)
I'm worried that 32-bit is going to become a second-class platform,
given that any new development is going to happen on gcc5, and that (for
reasons stated elsewhere) I believe that 32-bit hardware is going to be
the largest potential userbase.
gcc2h + x86_64 is the "don't change anything" plan. It is mostly what we
are doing, except we make x86_64 a *second* officially supported
platform.
While supporting 32bit machines apparently makes some sense for a few
people, not supporting 64bit makes no sense at all. We don't want to be
like MorphOS where you have to buy a 10 year old machine to run the OS.
Is there any technical reason why this couldn't be gcc5 with gcc2 as the
secondary architecture? That way all the gcc5 stuff can be used in core,
with the gcc2 stuff retained as a compatibility layer on top of it for
legacy BeOS apps.
There is no technical reason, but all the effort for the last 15 years
has been on gcc2hybrid and we are very close to a release. Switching now
would require more efforts in rebuilding packages, testing that
everything works as expected, etc. All this for no clear gain for users
("gcc5 can be used in core" is not a gain for users).
Hence the proposal to release beta1 as gcc2h + x86_64, and maybe switch
to gcc5 as the main compiler in R2. This way, gcc5 can be used in core,
but in the *next* release, which avoids delaying beta1 further to cram
in yet another structural change. We have had enough of that with the
package management system.
Seems this sane plan is already decides, but here is my +1... :-)
Best regards,
Stephan
