[haiku] Re: Binary Compatibility Combinations
- From: PulkoMandy <pulkomandy@xxxxxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Mon, 7 Sep 2009 09:57:06 +0200
Note ARM is a 32-bit only system and as there is no binary
compatibility needed with R5, it will probably run only with gcc4.
The 64 vs 32 bit problem ca be solved the same way as the gcc2 vs
gcc4, using an hybrid build providing both a 64bit and a 32bit version
of all important libs, so the 32bit apps can run on 64bit systems.
However it is of course impossible to run 64bit apps on 32bit systems.
I think the simplest solution to avoid this mess is to release R1 as a
32bit only system, with both gcc2 and 4 available, and to release R2
as gcc-4 only, with 32 and 64bit flavours.
And then... the package manager will know what to do and tell you if
you try to install the wrong bundle.
And yes, when you have 8 different combinations (add PPC and 68k to
that), you don't want fat binaries. Haikuis lightweight, sure, but
there is no reaon to have 7/8 of each application being useless code
for other platforms. Fat binary is fine when you're apple and want to
use them temporarily for a smooth transition between two archs, not
when you want your system to run everywhere.
Mon, 07 Sep 2009 02:31:53, Michael Lotz <mmlr@xxxxxxxx>:
>> Back on BeOS we had three sets of binaries for many applications (R5,
>> Dano,
>> Zeta). It isn't unreasonable to think that Haiku users might have
>> even more
>> choices to be confused about. For example, there's x86 or ARM, 32
>> bit or 64
>> bit, and GCC2 or GCC4. Eight possible, but binary incompatible,
>> combinations. Hybrid builds might take care of GCC2/4 and the other
>> two
>> cases are fairly niche, but I doubt this problem can be ignored
>> forever.
>> ARM netbooks are likely a good match for Haiku, and eventually we'll
>> want 64
>> bit support.
>
> The GCC2/4 issue is taken care of by the hybrid builds. Sooner or later
> (actually with R2) we will switch to GCC4 only anyway so this one will
> go away.
>
> The 32bit vs. 64bit is only relevant for drivers. Once we support x86_
> 64 it doesn't matter from an application side, as an x86_64 OS can run
> both 64bit and 32bit applications. Only the kernel bits and driver bits
> need to be compatible. It will however require 64bit OS libraries. This
> will only add one set of libraries though as there will only be GCC4
> 64bit libraries.
>
> The only real issue is with different architectures. I'm not a huge fan
> of fat binaries as they simply waste bandwidth and diskspace.
> Realistically seen the only real platform apart from x86 seems to be
> ARM. I would say this one case can be handled by an educated user.
>
> What you are describing though is a set of binaries for different
> releases of the same OS. These existed for a specific reason: not
> everyone migrated to the newer release. You couldn't really ask
> everyone to migrate to Dano as it wasn't actually a release (and had
> its set of issues). And not everyone really liked ZETA and stayed with
> R5 instead. So there was demand for binaries for older platforms. If
> everyone migrated to ZETA it wouldn't have been an issue, as ZETA ran
> R5 and Dano binaries just fine afterall. The same will be true for
> Haiku. If everyone migrates to R2 when it's here there will be no demand
> for R1 binaries anymore, so they won't get made. If R2 turns out to be
> a major disappointment and half of the community stays with R1, you can
> expect there to be sets of binaries for both releases.
>
> Regards
> Michael
>
>
--
Adrien Destugues / PulkoMandy
Elève ingénieur ENSSAT EII1- www.enssat.fr
GSoC student for Haiku - http://haiku-os.org
GrafX2 project team - http://code.google.com/p/grafx2
Other related posts:
