> From: Cameron Simpson <[EMAIL PROTECTED]> > > On 14:51 18 Feb 2002, Dave Reed <[EMAIL PROTECTED]> wrote: > | I'm just trying to understand something here. . . I skimmed the > | release notes for the 1.3.14 development version of glib/gtk and it > | contained: > | > | The API is frozen at this point. No additional API changes are > | anticipated before GTK+-2.0 is released. > | > | <snip> > | > | Binary interfaces for these libraries are not yet frozen; applications > | built against these libraries will need to be rebuilt when the > | final GTK+-2.0.0 is released. > | > | How is it possible for it not to be binary compatible if none of the > | source API functions change? > > Several ways. Some examples: > > The Binary API for C++ is different between gcc 2.95 (RH 6.x systems), > gcc 2.96 (RH 7.x) systems _and_ gcc 3.x. So programs compiled for each
Yes, that I understand. > will not mutually link. However, that's not what the gtk people will be > talking about. > > More likely example: Suppose something is a macro in one release and a > real function in another. The source API will be the same (you call the > macro just like a function) but there will be no library symbol for the > version using a macro. Another instance is constants. Supposing there's > a set of bitmasks like: > > #define M_THIS 0x01 > #define M_THAT 0x02 > #define M_THEOTHER 0x04 > > in one release and they're numbers 2,4,8 in another. The source API > again would be the same because you'd be talking in terms of M_THIS etc, > but the actual numbers used in the binaries would differ. Ah, I hadn't thought of that. Thanks, Dave _______________________________________________ Redhat-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-list
