Re: [PATCH] Remove unused libgfortran functions

[Janne Blomqvist <blomqvist.janne@gmail.com>]

On Mon, Dec 19, 2016 at 12:59 PM, FX <fxcoudert@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