To view parent comment, click here.
To read all comments associated with this story, please click here.
How can this particular ABI breakage cause frustration for the average ISV dev on the gnu c++ platform? If a developer is only targeting 32-bit x86 (which until 64 bit linux becomes far more widespread, this is going to be the vast majority of ISV's) this particular ABI change will have ZERO impact, and the ABI is exactly the same as it was in gcc 4.0 and 3.4.
How can this particular ABI breakage cause frustration for the average ISV dev on the gnu c++ platform?
See, now you're qualifying it. You're trying to "wiggle out" of the point that there are ABI changes. First your claim was that there were no ABI changes, then your claim was only for a certain platform, and now your claim is that it doesn't affect the average (whatever that is) isv. You keep narrowing the scope of your claims.
Remember, the whole discussion was regarding my point that the ABI keeps changing. I don't care what part of the ABI does change. ABI changes are difficult, annoying, and should have been unnecessary with the proper foresight and planning on the part of the gcc team. Many other platforms have managed to maintain their ABI decades without issue. Only the GNU platform seems to manage to screw it up every year.





Member since:
2005-07-06
Basically, this is only a partial abi breakage on 64-bit binaries with data segments that can exceed 4 GB. Anything that is 32-bit only (as is the vast majority of ISV-ware) is unaffected.
The point is, the ABI keeps changing. Even partial breakage is still breakage.
It only adds to the frustration of developers using the platform.