Closed terminator356 closed 1 year ago
Until today I have been using my distro's rtaudio package which is version 5.1.0 So just to be sure, I built and installed rtaudio 5.2.0 This time our app finishes compilation and linking OK.
So definitely version >= 6 is giving me the above stated trouble. Thanks.
As far as I know, nothing changed in the build system in going from version 5 to version 6. Do the programs in the tests/ directory compile and link for you?
Yes, I just tested the 'playsaw' test. I hear the saw OK.
Strange. I thought that maybe we must grab the RTAUDIO_CFLAGS that cmake passes to us from the package config (.pc) file, and add them to our app's flags. LINUX_ALSA, LINUX_PULSE etc. That did not work. Version 6 still did not allow the app to finish linking. Although with version 5.2.0, it did suddenly make the various APIs in the header file visible. But it seems this step is not really necessary for normal operation.
I am baffled. I tried all day, no luck.
Success!
I was forced to remove my distro's rtaudio package! Our app was linking with the wrong library.
This should not happen. User-built versions of software in /usr/local are usually never interfered with by packaged versions in /usr.
I think the problem is version numbering. The packaged version was 5.1.0, and that is what it says in its .pc file. But the actual library files are labelled as 6.0.1 Meanwhile my built 6.0.1 version says 6.0.1 in its .pc file. But the actual library files are labelled as 7.0.0
I think this caused my compiler great confusion. I think it went and looked at the local-built .pc file seeing 6.0.1 but then it actually linked the libraries labelled as 6.0.1 which are part of my distro's package.
I even tried manually typing ldconfig to be sure that the system was pointing to the correct files. In the distant past sometimes this was necessary after a build. But it did not help here.
I hope this experience gives an idea of how to proceed with the numbering scheme. It seems the version numbers in the .pc files should really match what the library file numbering says. Otherwise this is what can end up happening.
Thanks.
The rtaudio.pc.in is using PACKAGE_VERSION and not the soversion. Versioning in CMake and Meson got some attention here. I just tested Meson and it also didn't do the right thing. How did you build rtaudio?
My wording wasn't good. AFAIU the behavior right now is correct. I don't think the lookup of the shared object takes into account that there could be multiple versions installed. Correct me if I'm wrong! To make this work we would need to add the API version to the library name. Instead of rtaudio the dependency would be called rtaudio-6 and the library filename librtaudio-6.so.7.0.0.
I correct myself. It is too late. I was thinking about the build process. You have version 5.2 and 6.0. Your program depends on 6.0. So you take the pkgconfig file for it. That file doesn't know anything about soversions. It just adds the libdir path with prefix /usr/local. But you probably also link with -l /usr/lib64. So it finds your old version of rtaudio and fails.
Sorry for the spam!
Hello. We have used rtaudio for several years now.
Today I tried building and installing either version 6.0.0 or 6.0.1 No errors. Seems fine.
I have added the necessary support for >=6 in our app. Minor changes, really. Three places: Error returns, and checking if the DeviceInfo ID is non-zero instead of checking the old 'probed' member.
But when building our app I am now getting four missing rtaudio library symbols, as shown in the printouts below: RtAudio::RtAudio (constructor), RtApi::getDeviceInfo, RtAudio::openStream, and RtApi::getDeviceCount.
I've checked and tried everthing I can think of. Any ideas what could be wrong? Thanks.
Some output: