removed function in 1.7.1 without soname bump
Hi all, I'm a Fedora co-maintainer for ginac. We're currently working on updating ginac to the new release 1.7.1. During this process, we realized that there is a function that was removed in 1.7.1, but the soname was not changed. Was this intentional? Usually, removing functions requires an soname bump so other software doesn't accidentally link against the wrong version. The removed function is 'method virtual GiNaC::ex GiNaC::pointer_to_map_function_1arg<const GiNaC::ex&>::operator()(const GiNaC::ex&)' I've attached the output of abidiff to this email. For reference, here is the exact command to get the abidiff: $ abidiff --d1 ginac-old/usr/lib/debug/ --d2 ginac-new/usr/lib/debug ginac-old/usr/lib64/libginac.so.6.0.0 ginac-new/usr/lib64/libginac.so.6.0.1 Kind regards, Till
On 10/04/2016 09:47 AM, Till Hofmann wrote:
I'm a Fedora co-maintainer for ginac. We're currently working on updating ginac to the new release 1.7.1. During this process, we realized that there is a function that was removed in 1.7.1, but the soname was not changed. Was this intentional? Usually, removing functions requires an soname bump so other software doesn't accidentally link against the wrong version.
The removed function is 'method virtual GiNaC::ex GiNaC::pointer_to_map_function_1arg<const GiNaC::ex&>::operator()(const GiNaC::ex&)'
I've attached the output of abidiff to this email. For reference, here is the exact command to get the abidiff: $ abidiff --d1 ginac-old/usr/lib/debug/ --d2 ginac-new/usr/lib/debug ginac-old/usr/lib64/libginac.so.6.0.0 ginac-new/usr/lib64/libginac.so.6.0.1
Thanks, Till, for this report. Such attention is highly appreciated! The removal of that function was unintentional. It somehow slipped through my review with c9e4e59d. I will do a release 1.7.2 these days with just this fixed. -richy. -- Richard B. Kreckel <http://in.terlu.de/~kreckel/>
Hi, On 10/05/2016 12:08 AM, Richard B. Kreckel wrote:
I will do a release 1.7.2 these days with just this fixed.
No, wait! The function 'method virtual GiNaC::ex GiNaC::pointer_to_map_function_1arg<const GiNaC::ex&>::operator()(const GiNaC::ex&)' removed from the ABI is this template class method operator() declared in <ginac/ex.h>: template<class T1> class pointer_to_map_function_1arg : public map_function { protected: ex (*ptr)(const ex &, T1); T1 arg1; public: explicit pointer_to_map_function_1arg(ex x(const ex &, T1), T1 a1) : ptr(x), arg1(a1) {} ex operator()(const ex & e) override { return ptr(e, arg1); } //!!! }; What happend is that a GiNaC-internal static function has stopped using a pointer_to_map_function_1arg<const GiNaC::ex&> object. Please correct me if I'm wrong, but I suppose that any program/library linked against GiNaC will have to get its own copy of that method at compile time. And that makes this *not* an ABI breakage, right? -richy. -- Richard B. Kreckel <http://in.terlu.de/~kreckel/>
On 05.10.2016 10:16, Richard B. Kreckel wrote:
Hi,
On 10/05/2016 12:08 AM, Richard B. Kreckel wrote:
I will do a release 1.7.2 these days with just this fixed.
No, wait!
The function 'method virtual GiNaC::ex GiNaC::pointer_to_map_function_1arg<const GiNaC::ex&>::operator()(const GiNaC::ex&)' removed from the ABI is this template class method operator() declared in <ginac/ex.h>:
template<class T1> class pointer_to_map_function_1arg : public map_function { protected: ex (*ptr)(const ex &, T1); T1 arg1; public: explicit pointer_to_map_function_1arg(ex x(const ex &, T1), T1 a1) : ptr(x), arg1(a1) {} ex operator()(const ex & e) override { return ptr(e, arg1); } //!!! };
What happend is that a GiNaC-internal static function has stopped using a pointer_to_map_function_1arg<const GiNaC::ex&> object.
Please correct me if I'm wrong, but I suppose that any program/library linked against GiNaC will have to get its own copy of that method at compile time. And that makes this *not* an ABI breakage, right?
-richy.
Hi Richy, you're correct, and we've tested your hypothesis: If I use the removed function in some test code, it will show up in its symbol table, even with the 1.7.1 release; just as you expected. So 1.7.1 doesn't break ABI compatibility and there is no need for a 1.7.2. release. Thank you for your help in figuring this out! Kind regards, Till
participants (2)
-
Richard B. Kreckel
-
Till Hofmann