Re: What next?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>>>> "Mike" == Mike Hearn <mike@xxxxxxx> writes:

>> On Wed, 01 Jun 2005 14:09:06 -0700, Anthony Green wrote:
>> Most of the improvements of late imply ABI breakage because we're
>> extending the library in incompatible ways.  Restricting ourselves to
>> non-ABI-breaking changes in GCC 4.0.x limits our ability to continue to
>> demonstrate innovation.

Mike> Could you elaborate on that? In a private email exchange recently Tom
Mike> Tromey suggested that the ABI was stable (or very nearly stable) in that
Mike> apps compiled with GCJ 4.0 would run against a 4.1 system (but not
Mike> vice-versa unfortunately).

Yes.  There are 2 ABIs, and you are talking about one (the binary
compatibility ABI, aka BC ABI) while Anthony is talking about the
other one (the "C++" ABI).

Our current rule for hacking libgcj in the GCC tree is that we don't
break the C++ ABI in a minor release.  This is a very strict rule, it
means we can't do things like add new non-static methods (we can add
new classes and other things like that though).

While the new BC ABI is fairly solid, we put off really promising
long-term binary compatibility until GCC 4.1, on the theory that we
might have overlooked something.  And sure enough we found a couple of
bugs after shipping; but it turns out we can fix these without
breaking existing (4.0-compiled) binaries.

Mike> I'm afraid I'm also really convinced that breaking ABI
Mike> constitutes innovation, or even is required for it ... it's a
Mike> clone of Java so at most you would be adding new APIs which
Mike> hopefully the ABI design allows for?

Yeah, the new ABI was made precisely so we could make all the changes
to libgcj that we might need to make, while not breaking any existing
binaries.  The idea being that at some point (4.1 is our target) we
can just make the BC ABI the default one and only promise that we
won't break it, and let the C++ ABI break constantly.

One option for FC5 would be to go ahead and update libgcj.
All the BC-compiled code would still work.

Mike> I'm interested in this because I'm working with a guy who wishes to
Mike> distribute GCJ compiled binaries across multiple Linux distributions.

Should be ok as long as you pick a consistent required base version,
and compile everything BC.

Tom

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux