This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Remove unused libgfortran functions
On Fri, Dec 16, 2016 at 4:02 PM, FX <fxcoudert@gmail.com> wrote:
> A few questions:
>
> 1. Regarding gfortran.map, shouldn’t we just flatten out all the symbols from GFORTRAN_1.0 to GFORTRAN_1.7 into a single new GFORTRAN_2.0 group (while removing the ones we are getting rid of)?
Yes, I agree (in general, though I was thinking of making the new one
"GFORTRAN_7" to match the release series). 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. 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.
> 2. While we are breaking the ABI, shouldn’t we reorder the array argument to the libgfortran_set_options to remove unused fields?
Hmm, yes, probably. Can you add it to the libgfortranAbiCleanup page
on the wiki. Or better yet, get cracking, there's a lot to do.. ;-/
> 3. What will happen to people who try to run older compiled codes with newer library versions? Will it fail with an error message? Segfault? Do we have a way to make it fail in a better way?
It won't work, since old binaries are linked against libgfortran.so.3,
and GFortran 7 will provide libgfortran.so.4. But of course, you can
have both the so.3 and so.4 installed in parallel. The problem occurs,
say, when you have lib A that links against so.3 and lib B that links
against so.4, and your application wants to use both. In particular if
one or both of libs A and B are proprietary libs and you can't
recompile them against the same so version.. But also for the free
software world, these rebuild the world transitions tend to be
painful, which is why we have been so careful to not needlessly break
the ABI. But now it seems we'll have such an ABI transition both for
GCC 7 and 8, but that's another story.. :(
--
Janne Blomqvist