Linked by Thom Holwerda on Sun 10th Sep 2006 20:38 UTC, submitted by fudel
Permalink for comment 161173
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/25/13 0:45 UTC
Linked by Thom Holwerda on 05/24/13 23:59 UTC
Linked by Thom Holwerda on 05/24/13 22:33 UTC
Linked by Howard Fosdick on 05/24/13 21:41 UTC
Linked by Thom Holwerda on 05/24/13 14:44 UTC
Linked by Thom Holwerda on 05/23/13 23:22 UTC
Linked by Thom Holwerda on 05/23/13 22:04 UTC
Linked by Thom Holwerda on 05/23/13 22:01 UTC
Linked by Thom Holwerda on 05/23/13 17:52 UTC
Linked by Thom Holwerda on 05/22/13 22:23 UTC
More News »
Sponsored Links



Member since:
2006-05-26
To say "Some" applications wouldn't work anymore (unless they created a thunking library to convert between 2.9x gcc and 4.x gcc libs, which *could* be done) is correct for a very large number of applications. Any C++ applications (any that called into methods of the OS that weren't straight C linkage) including those that use the GUI at all would need to be recompiled, and might be source compatible, but they are not binary compatible, because gcc 2.9x and gcc after that (3.x-4.x) use a completely different C++ binary interface. Thus, without some hack thunking libraries, existing application binaries won't work with a new system built using gcc 4.x as a result.
If there's a good time to break the classes for size and layout, the transition to gcc 4.x would be the best time, if source compatibility is still desired, but they wanted to change the layout of classes. Better yet (though it is far from likely to happen with Zeta) would be to write the C++ API so it doesn't have the fragile base class problem (binary layout) but that will be both source and binary incompatible with what's currently available.