On Tue, Apr 10, 2012 at 11:21, Tobias Burnus <tobias.bur...@physik.fu-berlin.de> wrote: > Regarding ABI breakage: [snip]
In general I agree that ABI compatibility is something we should take seriously, but OTOH we should take care that the anointed ABI makes sense. Which IMHO would imply that known ABI bugs/misdesigns should be fixed, and e.g. the mod file format should be extensible. And even that may not be enough, considering there are rather big performance issues with mod loading at the moment, which may or may not require a complete redesign of the mod file format as well. So I worry that if we commit to supporting something more or less like the current mod format going forward, will that make solving these problems prohibitively tedious as one would need to at the same time support both the existing, possibly completely different module format, and the new one? Also, ideally we should have a document similar to what C++ has at http://sourcery.mentor.com/public/cxx-abi/ which describes the ABI. Also, while it would be nice to fix the ABI in one go, considering the rather limited manpower we have, maybe it's more feasible to spread it over several releases. Say if we update the array descriptor (and hence library .so version number) in one release, name mangling fixes and other "OOP ABI" issues in another, better .mod file format whenever it gets done, and so forth. And only when we're "done" we fix the ABI and implement the -fabi-version thingy (since inevitably ABI bugs will be found and fixed in the future as well, and also of course new language features may require updating the ABI). -- Janne Blomqvist
