On Mon, Aug 29, 2016 at 11:15 AM, Andre Vehreschild <ve...@gmx.de> wrote: > Hi all, > >> Anyway, a small nit I found was the function st_set_nml_var in >> libgfortran. This is an exported function, and thus part of the ABI. >> So you cannot add arguments to it, as that would break backwards >> compatibility. > > Please explain the above. I was of the opinion, that when we change > something significantly the global ABI version gets bumped. Given that > we are doing gcc-7 currently and there have been some changes, that ABI > version should have been bumped already with respect to gcc-6.
We strive very(?) hard to retain ABI compatibility for libgfortran, as having to recompile everything is a huge PITA for our users. As a result we have been able avoid bumping the SO major version number since GCC 4.3 IIRC. There is a long laundry-list of cleanups that could be done once we do bump the SO major version: https://gcc.gnu.org/wiki/LibgfortranAbiCleanup Probably when (if?) the new array descriptor is merged we have to do said bump, as that one is used everywhere and retaining compatibility with the old descriptor seems to be a huge undertaking. > I am asking that stupid question mostly, because during extending > coarray stuff to support allocatable components in derived typed > coarrays the API of the caf-library has to be modified and carrying > along the old signatures just causes useless garbage being carried > forward. (Opencoarrays is working on supporting the same renovated API. > Other users of that API are not known to me.) So what is the best way > to resolve this? I haven't involved myself in the coarray stuff, but AFAIU the corray lib hasn't been considered stable, in order that the developers can more quickly iterate on the design without having to be bogged down by ABI compatibility considerations. -- Janne Blomqvist
