This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [fortran, patch] IEEE intrinsic modules
- From: Janne Blomqvist <blomqvist dot janne at gmail dot com>
- To: Rainer Orth <ro at cebitec dot uni-bielefeld dot de>
- Cc: FX <fxcoudert at gmail dot com>, gfortran <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 5 Jun 2014 13:45:20 +0300
- Subject: Re: [fortran, patch] IEEE intrinsic modules
- Authentication-results: sourceware.org; auth=none
- References: <09EBE3B0-9CF4-4CB6-9E6D-C1FAFB9D81C8 at gmail dot com> <CAO9iq9GoHtsDssvSYisoL+q7c_Wts=iN=GcWQahZc55PM_3C_A at mail dot gmail dot com> <yddoay7yfmb dot fsf at CeBiTec dot Uni-Bielefeld dot DE> <yddvbsf64wg dot fsf at lokon dot CeBiTec dot Uni-Bielefeld dot DE>
On Thu, Jun 5, 2014 at 1:13 PM, Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote:
> Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:
>
>> Janne Blomqvist <blomqvist.janne@gmail.com> writes:
>>
>>> On Thu, Jun 5, 2014 at 1:04 AM, FX <fxcoudert@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.
libgcc_s and glibc seem to use such a scheme, suggesting that
competently maintained libraries can choose to do it that way.
> Besides, the request constitues a fundamental misunderstanding how
> interface (and symbol) versioning work.
Considering that yours truly was the one who originally added symbol
versioning to libgfortran, I dare claim that I have at least a
superficial understanding how it works, thank you very much. Back then
there was some discussion what kind of versioning scheme to use, and I
arbitrarily chose the current one.
> I bet those same users clamour
> to change the SONAME from libgfortran.so.3 to .so.4 to match the GCC
> major version ;-(
I haven't seen that particular complaint, but it's of course possible
that somebody complains about that.
> 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.
I think it's quite infeasible to get most GFortran users to care for,
much less learn about, such a topic.
> 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)
No, duh?
> and
> interface version to GFORTRAN_5.0 even if no symbols were added?
No, why would a new symbol node be added if no actual symbols are added?
Now, where I see a minor trouble is that if we first add a symbol node
"GFORTRAN_4.10", and then later on it is decided that the next release
will be 5.0. So then we should change the name of the symbol node to
match, which might cause issues for people who have been building
against trunk versions. But I guess that is par for the course when
using trunk.
--
Janne Blomqvist