On Mon, Dec 19, 2016 at 12:59 PM, FX <fxcoud...@gmail.com> wrote: >> Yes, I agree (in general, though I was thinking of making the new one >> "GFORTRAN_7" to match the release series). > > Given that there will not be a 1-to-1 mapping of release series with major > ABI versions (hopefully!), I don’t think this is a good idea. It will make > people confused.
I don't understand. Why would it imply a 1:1 mapping of release series with major ABI versions? Say we release GCC 7 providing libgfortran.so.4 (that is, major version 4) and gfortran.map has the symbols under the GFORTRAN_7 node. Later on we release GCC 8 and new library symbols there would have the GFORTRAN_8 node while keeping the GFORTRAN_7 node for existing symbols that are backwards compatible. Just like we currently have with GFORTRAN_1.0, 1.1, etc. (remember that the nodes in .map files are arbitrary identifiers, the number have no meaning per se). Then if a user has some code compiled against GCC 8 and tries to run the binary on a system providing only libgfortran from GCC 7, the user will get an error message that symbol node GFORTRAN_8 is not found. IMHO that error message is clearer than an error message saying that GFORTRAN_2.0 not found (to which the user replies, but I have GFortran 8 which is bigger than 2.0, WTF?? And yes, I've seen exactly this happen). >> There's also other things, >> like e.g. ISO_C_BINDING helper functions living under the >> __iso_c_binding namespace, instead of under _gfortran like everything >> else. > > Agreed. Which seems to be a moot point, since you just removed all those symbols entirely. :) >> And while we're at it, should we place everything under >> "__gfortran" or "_GFortran", that is, with two underscores or one >> underscore followed by a capital letter which in the C world is >> reserved for the implementation? Though it's not clear to me whether >> libgfortran can claim to be part of "the implementation" vs. being >> generic user code. > > Another issue is that we have some documented, user-callable functions that > currently live in the __gfortran_ “namespace”, e.g. the mixed-language > routines > (https://gcc.gnu.org/onlinedocs/gfortran/Non-Fortran-Main-Program.html). We > want to avoid changing those for no reason, and so for consistency I think we > should keep everything under __gfortran_ Currently we have _gfortran_, that is with a single underscore in the beginning, so it's not in the "C/POSIX reserved for the implementation namespace". But yes, I agree that at least those functions documented under the non-Fortran main program section in the manual should be kept as is. -- Janne Blomqvist
