[openbeos] Re: binary compat [was Re: Re: BFS and encryption.]
- From: "Mikael J." <tic_khr@xxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Fri, 18 Jan 2002 16:07:24 +0100
>
>>whoah Marcus, calm down, stop seeing conspiracys everywhere.
>>im not trying to start a flame war, and im sure neither is helmar.
>
>We really are all on the same side here. Please, everyone, treat each
>other kindly.
>
>>there have been a few compelling reasons for breaking binary
>>compatibility mentioned back when R5 was still being worked on be
>>be,inc (gcc 3.0, better kernel virtual memory , performance issues,
>>etc), so it might not be a bad idea to consider doing so if there are
>
>Of these, only GCC requires a real binary compatability break. And that
>is only maybe.
>
>>compelling reasons for us to do so. yes, it would be a good thing to
>>keep compatability if possible, but it should not be so sacred that we
>>get into the mess of trying to keep compat with a 20 year old os. ;)
>>Be,inc completly broke binary compat once, and there were minor breaks
>>each release.
>
>The only decision we have reached on this line is that R1 will *NOT*
break
>compatability unless it absolutely has to.
>
>>that being said, if you can keep binary compat please do, it would
make
>>everyones life simpler. i will be trying to. its really the kernel/IK
>>people that will make or break it.
>
>The facts, as I see them, are this:
>
>binary compatability means that the kernel can load an R5 app. Link it
to appropriate .so's. And execute it.
>It has *nothing* to do with the internal workings of the kits. Only the
interface (i.e. things like number of virtual functions)
>must remain the same. That is why GCC3 breaks bin compatability - they
reworked the whole way that the
>binaries look. That is *not* to say that it would be impossible to have
OBOS read *both*. Caveat - I have not looked
>in depth at GCC 3. The ELF loader is generic. The linking mechanism
should also work - the names are different, but the
>methodology should work. In fact, the way I see it, we could even build
libbe.so (compatability version) and libbe.so (new version with GCC3).
New apps, that know about the new version would load it. Note that I
didn't indicate the mechanism for determining. That is alwasy flamewar
fodder. :-)
>
How about libbe.so.1 etc., like in the UN*X world? Would definitely make
shared libraries easier to manage (both system-wide and user), for
situations like these.
--
Mikael J @ http://hem.spray.se/tic_khr
Other related posts:
