Rainer Orth <r...@cebitec.uni-bielefeld.de> writes:
> Janne Blomqvist <blomqvist.ja...@gmail.com> writes:
>
>> On Thu, Jun 5, 2014 at 1:04 AM, FX <fxcoud...@gmail.com> wrote:
>>> 2. Your review of the patch!
>>
>> Not a full review, just a few quick comments.
>>
>> - Wrt. libgfortran/gfortran.map: You have added the GFORTRAN_1.6
>> symbol node, as you're the first one to export new symbols in the 4.10
>> cycle. I've seen occasional confusion from users when they have symbol
>> version mismatches and e.g. "1.4" doesn't match any version they've
>> seen before. So I think it might be better to switch to a scheme where
>> the symbol node name matches the compiler version, i.e. GFORTRAN_4.10.
>
> Except libgcc_s.so.1, none of the other GCC runtime libraries does
> that. Changing schemes in the middle is going to be even more confusing
> than staying with what we have here. The only other reasonable scheme
> is what libgomp.so.1 does, namely naming the versions after the OpenMP
> standard they implement.
Besides, the request constitues a fundamental misunderstanding how
interface (and symbol) versioning work. I bet those same users clamour
to change the SONAME from libgfortran.so.3 to .so.4 to match the GCC
major version ;-( Tell them to read up on interface vs. release
versioning in the libtool manual; symbol versioning is just a more
granular version of interface versioning.
Imagine the next version of gcc is called 5.0 instead of 4.10. Would
you change the SONAME to .so.5 (suggesting an incompatible change) and
interface version to GFORTRAN_5.0 even if no symbols were added?
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
