Bugzilla – Bug 280
Release a versioned libresample to allow Audacity to be safely compiled --with-libresample=system
Last modified: 2018-08-20 11:46:16 UTC
"./configure --without-libsamplerate --with-libresample=system" will always tell you "configure: error: You requested using the system libraries for LIBRESAMPLE but they are not available", but it doesn't check if libresample is installed on the system. The code for checking the system libresample is missing in m4/audacity_checklib_libresample.m4.
As far as I've been able to determine, there are 2 main causes for this: m4/audacity_checklib_libresample.m4 is only half written (the areas where checking for system libraries is done) libresample only compiles to a static file (although I'm not totally sure whether these libraries are used static or dynamic, the Makefile for libsamplerate is over my head), and no proper resample.pc file is created so pkg-config never finds resample, resulting in configure failing. I've mucked around my system trying to fix it, but I've had to compile libresample.so, hand write resample.pc, and attempted to merge m4/audacity_checklib_libsamplerate.m4 and m4/audacity_checklib_libresample.m4 to no avail. But since I just started to learn M4, pkg-config, and am very rusty on GCC I think someone else should take a look and see if they can fix it.
See also last paragraph in http://wiki.audacityteam.org/wiki/Libresample Linking to a system Libresample probably should be disabled. "It's worth noting that although things called libresample crop up in various distributions and other packages (e.g. Asterisk), none of them are the same as what Audacity is using, although they all share common parentage. As a result we (Audacity) don't support or test linking to any of these libraries. "
"none of them are the same as what Audacity is using" I downloaded the libresample source package from Debian (version 0.1.3-4) and compared it with libresample from Audacity's lib-src directory. The diff showed huge modification in the build system and in the auto-generated files (configure, config.guess, ...), but only two modified lines in the .c and .h files. These two changes affected only the C preprocessor. Therefore I proved the quoted sentence wrong.
Created attachment 72 [details] libresample.patch The attached patch made audacity detect and correctly use the system libresample library.
The comments that "our libresample isn't the same as anyone else's" (28 Dec 2009) are attributed to Richard, so can't be dismissed out of hand. Default ./configure of HEAD gives you (our) libresample. Ubuntu packages of Audacity (and others?) currently use libsamplerate which is either pretty buggy and broken (or Audacity's interaction with it is), so some users would no doubt prefer to use (our) libresample. But what is the scenario for this bug - who is this fix useful for? Do we need to link to a possibly different libresample when (our) libresample is in Audacity's lib-src directory? And if an external libresample is not the same as ours and this causes bugs to appear in Audacity, isn't that a consideration?
> But what is the scenario for this bug - who is this fix useful for? If you apply this patch, I will change the Debian/Ubuntu package to use libresample instead of libsamplerate. Feel free to use the local libresample if not specified otherwise with configure. Planned changes to the configure flags: ./configure --without-libsamplerate --with-libresample=system > And if an external libresample is not the same as ours and this > causes bugs to appear in Audacity, isn't that a consideration? Some checks can be put into the configure script to detect if the system libresample has the needed functions.
libresample was written by Dominic for Audacity. Audacity has never provided releases of libresample as stand-alone tarballs, or had any support for building it outside the Audacity source tree (hence no .pc file, static lib only. For a long time it didn't even have a separate configure script). Anyone else shipping a "libresample" has either picked up an unknown date SVN snapshot (more likely CVS), or extracted it from an Audacity release (or it's a complete fluke name clash). They may have made changes to it. We may have made changes to our code since then, which they won't have. There is no version number to check to see if what the system has is suitable for Audacity. I think external linkage (until and unless we release a proper package with a version number and means of checking it) is asking for trouble we can't control. Is it worth it for the (small) amount of code involved?
Where does this libresample package comes from? https://ccrma.stanford.edu/~jos/resample/Free_Resampling_Software.html
(In reply to comment #6) > If you apply this patch, I will change the Debian/Ubuntu package to use > libresample instead of libsamplerate Using (our) libresample would certainly reduce support issues. But can't you do that without allowing linkage against system libresample?
Gale, Benjamin mentioned in the -devel list that Debian already has libresample, and he doesn't want to statically compile in a library that the system already has. That way if libresample has a security issue, he only needs to update it, not it and Audacity.
Although, if Debian is already using a package of libresample, and Benjamin is set on using the system's library for that, maybe it's time we release libresample as a stand-alone tarball? I'm assuming we don't change libresample that often, but that way we could be sure that any libresample packages floating out there are recent, rather than from some unspecified snapshot of our source tree.
Good idea. I recommend to add a pkg-config file. Then you can check the version in the configure script.
> Benjamin mentioned in the -devel list that Debian already has libresample, > and he doesn't want to statically compile in a library that the system > already has. Thanks, Ashton. So are e.g. libvamp and libsoundtouch in the Ubuntu/Debian Audacity packages linked to external versions of those libs? Would statically linking to our libresample be a sole exception to general practice? > maybe it's time we release libresample as a stand-alone tarball? What guarantee is there that all Linux distros would use it if there are already other versions around? Would we have to call it "audacity-libresample" to make it clear? Are minor distros' libresample libs going to be as well maintained as Debian and Ubuntu? If there are version number/function checks it seems like we could be in "FFmpeg hell" (a sample rate conversion library isn't all that optional).
That depends on what all the libresample's that are floating out there are. If they're just orphaned snapshots of our libresample, then we just declare this to be a newer version, and set the requirements to be at the new version or higher if using system libraries. If they are genuinely different libresamples, with no similarity to the one we are using, a name change could be in order. Besides, I don't think anyone is implying that we should set Audacity to automatically compile using the system's libresample. I'm betting a lot of other distros don't even provide libresample, and just compile it in statically. I believe Arch does that, because I don't see libresample in the repos, although I've never installed Audacity from pacman.
> So are e.g. libvamp and libsoundtouch in the Ubuntu/Debian > Audacity packages linked to external versions of those libs? Yes, only two local libraries are used because they are not yet in the archive (but I am currently packaging them). > Would statically linking to our libresample be a sole > exception to general practice? Please look at §4.13 of the Debian Policy [1]. [1] http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles
Thanks for the input. There seem a number of conflicting messages here e.g. you could argue that since we don't allow to configure with system libresample we are intending "our" version to be used as a "convenience" library. OTOH (without wanting to disparage SRC) it seems there are licensing and support advantages in encouraging Audacity to be compiled with the default libresample. Since no Team developers have spoken in favour of simply allowing use of system libresample, I've made this a P4 enhancement "Release a versioned libresample to allow Audacity to be safely compiled --with-libresample=system". That's not set in stone, just to make some kind of decision about handling it.
I think I'd be willing to take up the mantle on moving libresample out into the wild after 1.3.13 is out. I doubt I'll be able to learn enough about libraries to make it in time for 1.3.13, and I don't want anyone waiting on me.
This is all irrelevant now that the default resampler is libsoxr. We will not be maintaining/supporting/releasing libresample.
