On Fri, 15 Jul 2022 12:21:53 -0400 Tim <termtech(a)rogers.com> wrote: Sound interesting :) When you say higher CPU cost, can you give a rough estimate as to how much? Is it possible to have both versions compiled, and for a host to switch between them at runtime? -- Will J Godfrey {apparently now an 'elderly'} https://willgodfrey.bandcamp.com/ http://yoshimi.github.io Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song.

On Fri, 15 Jul 2022, at 23:02, Robin Gareus wrote: Thank you! Yes to both... I hope. The version in the .pc file is written in at install time, although I guess it would be nice to have the right version in place in .pc.in in the first place (or to omit it until installation) as it does look kind of confusing. The ABI has been at 2.something since version 1.2, which was the last release to break binary compatibility. This release bumped it from 2.1.7 to 2.2.0. A program dynamically linked against version 1.2 will still run correctly against this new version. But I find that after all these years I am still not totally clear on whether a *compatible* change to the ABI should cause a change to the soname, or only to the minor number. I thought I knew this, but I find now that sources contradict each other, and sometimes themselves, with great confidence - and it's been such a long time that I can no longer remember exactly why I formed my own view in the first place. For example: https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html section 3.1.1 "The soname has the prefix ``lib'', the name of the library, the phrase ``.so'', followed by a period and a version number that is incremented whenever the interface changes". This implies that if you e.g. add a function, you should change the soname. section 3.6 "When a new version of a library is binary-incompatible with the old one the soname needs to change... you can keep your Application Binary Interface (ABI) compatible if you avoid such changes. For example, you might want to add new functions but not delete the old ones". This implies that if you add a function, you need not change the soname. I always took the view that if the library can be upgraded without breaking an application linked against the old version, it should have the same soname (i.e. first component of ABI version) because the alternative would be too annoying in practice. That seems consistent with many other libraries, anyway. But it does mean that library downgrades don't fail cleanly and I am definitely finding sources out there that suggest it isn't the right thing to do after all. Has consensus on this changed over the years perhaps? Chris

On Thu, 28 Jul 2022, at 15:26, Fons Adriaensen wrote: I guess you're right (and thank you also for the kind words earlier on this list by the way!) It hadn't really occurred to me to think of the soname as marketing, but an increment does indicate novelty to humans as well as the machine. I am perhaps too invested in backward compatibility as the arbiter for this. Chris

On Thu, 28 Jul 2022, at 17:06, Robin Gareus wrote: Oops. How are you installing? If I use e.g. "meson build && ninja -C build && ninja -C build install" here I get a copy that does have the right version in it. I haven't looked too closely at how it does that though. Since it appears to work equally well with %VERSION% in the .in file, and it's obviously not great to have a wrong literal value in there, I'll make that change. That page just makes my head spin a little faster if anything! It seems rather libtool-specific and doesn't indicate how current:revision:age maps on to the installed library suffix. Is "current" the soname number, "revision" the minor number, and "age" the point number, as I would naively read it? If so, then it appears to be saying that merely adding a function *should* result in incrementing the soname: "If any interfaces have been added, removed, or changed since the last update, increment current, and set revision to 0" where "current" is the soname, right? As I read it, it seems to be saying that if the current version is (say) 2.1.7, then a backward-compatible addition should result in an updated version 3.0.8 whereas an incompatible change should result in 3.0.0. I'm not sure I understand the logic regardless of the explanation in the page. I don't recall having ever read quite that method before. Chris

On Thu, 28 Jul 2022, at 20:35, Yuri wrote: Thanks - there is a report of this here https://github.com/breakfastquay/rubberband/issues/66 and I'll take a look at it soon. (I'm just catching up on issues and threads today after a few days away) Chris