On 2016-12-02 10:48, Axel Dörfler wrote:
Am 01.12.2016 um 17:08 schrieb Adrien Destugues:
R1a4 was 32bit only, but I think we can make beta1 the first release
to officially support 64bit. This kind of solves the gcc2 problem by
itself.
Have you really thought this through yet?
Anyway, I guess I cannot just miss out on such a discussion :-)
I think we need to clearly plan our ABI future and changes, before
doing anything different from what we're doing now (slooowly working
towards R1, that is).
We have the general options (Compatibility is maintained between
releases unless otherwise mentioned):
1) Use gcc2 as stable ABI, anything else is experimental (and that
would therefore also include the x86_64 ABI). gcc2h is the default
release.
2) Like 1, but the default release would be gcc5h -- IOW the
replicants/screensaver/etc. ABI would not be stable.
3) Declare current gcc5 as our stable ABI, but keep gcc2 around for
compatibility, ie. gcc5h, too.
4) Declare current gcc5 as our stable ABI, and ditch gcc2 completely, ie. gcc5.
5) Declare both gcc2, and gcc5 stable. This would require us to
maintain another compatibility layer in the future. gcc2h.
6) Like 5, but with gcc5h instead.
7) Like 5 or 6, but only maintain binary compatibility between major
releases. This is pretty much how the Linux world works.
Each option has its own set of advantages and disadvantages.
1) was our answer to this question so far; personally I wouldn't mind
much between 1) and 2). I find having a current ffmpeg and libraw
quite tempting, at least.
I'm still doing my taxes with Gobe Productive, so I'm very interested
in keeping gcc2 alive as long as possible :-) Perhaps until a valid
successor becomes available on Haiku, though.
But no matter how we decide, some options require more work than others.
Also, I would like to examine our options to make our packages more
ABI agnostic so that you can use the same package no matter if you're
using gcc2h or gcc5h. That would make us a lot more flexible with
regards to that stuff.
