Re: [LAD] Rubber Band Library v3.0.0 released
On Thu, 28 Jul 2022, at 20:35, Yuri wrote:
> There are 4 LV2 plugins. Carla loads plugins without "R3" in them.
> But these 2 fail to load: Rubber Band R3 {Mono|Stereo} Pitch Shifter.
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
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Rubber Band Library v3.0.0 released
Hi Chris,
I tried to load LV2 plugins into Carla.
There are 4 LV2 plugins. Carla loads plugins without "R3" in them.
But these 2 fail to load: Rubber Band R3 {Mono|Stereo} Pitch Shifter.
Carla says:
Failed to load plugin
Could not find the requested plugin URI in the plugin library
Carla-2.5.0
FreeBSD 13.1
Thanks,
Yuri
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] library soname, was Re: Rubber Band Library v3.0.0 released
On Thu, 28 Jul 2022, at 17:06, Robin Gareus wrote: > On 7/28/22 15:52, Chris Cannam wrote: >> >> The version in the .pc file is written in at install time, > > Except, it isn't. $PREFIX/lib/pkgconfig/rubberband.pc here has Version: > 1.8.2 for rubberband v3.0.0 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. >> The ABI has been at 2.something since version 1.2, > > Yeah that's fine. I was just surprised to see the age being zero. > > http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] library soname, was Re: Rubber Band Library v3.0.0 released
On 7/28/22 15:52, Chris Cannam wrote: > > The version in the .pc file is written in at install time, Except, it isn't. $PREFIX/lib/pkgconfig/rubberband.pc here has Version: 1.8.2 for rubberband v3.0.0 the .pc.in file likely needs a placeholder %VERSION% so that it is replaced at install time. > The ABI has been at 2.something since version 1.2, Yeah that's fine. I was just surprised to see the age being zero. http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html -- robin OpenPGP_signature Description: OpenPGP digital signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] library soname, was Re: Rubber Band Library v3.0.0 released
On Thu, 28 Jul 2022, at 15:26, Fons Adriaensen wrote: > In this case you didn't just add a function, but a completely new and > improved algorithm. That's reason enough to increment the major version, > even if only for 'marketing'. And more so if you also offer a commercial > license. 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] library soname, was Re: Rubber Band Library v3.0.0 released
On Thu, Jul 28, 2022 at 02:52:03PM +0100, Chris Cannam wrote: > This implies that if you add a function, you need not change the soname. In this case you didn't just add a function, but a completely new and improved algorithm. That's reason enough to increment the major version, even if only for 'marketing'. And more so if you also offer a commercial license. Ciao, -- FA ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] library soname, was Re: Rubber Band Library v3.0.0 released
On Fri, 15 Jul 2022, at 23:02, Robin Gareus wrote: > Congrats on the release and thanks for the very informative blog post. Thank you! > https://hg.sr.ht/~breakfastquay/rubberband/browse/rubberband.pc.in?rev=v3.0.0 > > states Version: 1.8.2 (not 3.0.0). > The ABI version of the shared object is 2.2.0 > > Is that expected? 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
