I’m trying to compile an SC plugin for MacOS. There have been a couple of threads on this message board about this - and I made the mistake of piggybacking on one of them earlier, but I realized this might be a little different than the previous discussion, on account of my relative unfamiliarity with cmake and Terminal functions.
This is the error message, in full:
CMake Error at QtCollider/CMakeLists.txt:26 (find_package):
By not providing "FindQt5.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "Qt5", but
CMake did not find one.
Could not find a package configuration file provided by "Qt5" (requested
version 5.7) with any of the following names:
Qt5Config.cmake
qt5-config.cmake
Add the installation prefix of "Qt5" to CMAKE_PREFIX_PATH or set "Qt5_DIR"
to a directory containing one of the above files. If "Qt5" provides a
separate development package or SDK, be sure it has been installed.
Call Stack (most recent call first):
lang/CMakeLists.txt:184 (include)
Now, I’m pretty sure I have Qt5 installed. In fact, I double-checked by running brew install qt@5, where it returned with confirmation that I was installed and up-to-date.
My understanding is that I need to reference a “prefix path” in my compile code, something like this:
The issue is that there doesn’t seem to be an “/opt/QT5.15.13”. I can’t actually seem to find where the QT is that I need to refer to.
I understand the sheer stupidity of asking a forum where my QuickTime is located - but I hope that some of the more skilled users here can help me figure out what I might be missing in this compiling process and that it would help other newbies.
Wow - I probably would’ve never imagined that qt was a different framework, so this is a huge help already - thank you!
I think I have one more step, though, that maybe you’ve encountered.
brew info qt@5 does reveal several paths:
If you need to have qt@5 first in your PATH, run:
echo 'export PATH="/opt/homebrew/opt/qt@5/bin:$PATH"' >> ~/.zshrc
For compilers to find qt@5 you may need to set:
export LDFLAGS="-L/opt/homebrew/opt/qt@5/lib"
export CPPFLAGS="-I/opt/homebrew/opt/qt@5/include"
I ran the “echo” command, hoping to bring qt into the folder of the plugin I was compiling - though I didn’t see a chance in the folder and it threw the same error as in the first message. I also ran the '“echo” command again in the root directory (/Users/Scott/) - no luck there.
Then, I attempted to use cmake .. -DCMAKE_PREFIX_PATH= with the following paths: /opt/homebrew/opt/qt@5/lib ~/opt/homebrew/opt/qt@5/lib /opt/homebrew/opt/qt@5/include ~/opt/homebrew/opt/qt@5/include /opt/homebrew/opt/qt@5/ ~/opt/homebrew/opt/qt@5/
All produced the same error. I suspect I’m close - but I feel like I’m missing something else simple that’s probably obvious to people who have been working with this for awhile.
That echo command (specifically the >> bit) is just a silly way to add a line to the environmental path of the shell… Shells are a whole thing.
Before looking at that… I read you are trying to build a plugin, I don’t think you need supercollider built for that. Have you just tried building the plugin and setting the path? I don’t see why you’d need Qt for a server plugin.
I don’t see why you’d need Qt for a server plugin.
Me neither. What kind of plugin is this? In general, if you have trouble compiling certain software, it would be helpful to post a link to said software.
Sure - it’s Nick Collins’ “TopNFreq” - I don’t have much documentation on it and I’m assuming any technical problems are entirely my fault , but it’s located here: https://composerprogrammer.com/code/TopNFreq.zip
As expected, the TopNFreq UGen does not use Qt at all. I guess what happened was that you (accidentally) tried to build SuperCollider, which indeed depends on Qt.
Well, that makes some sense, although I’m still not able to successfully compile this plugin, though now I see it is for reasons other than I originally thought. Oddly enough, this process does not seem to throw the same “qt” error now, when I do the same thing as mentioned in the posts above.
If I run cmake -DCMAKE_BUILD_TYPE=Release cmake --build . --config Release, with no reference to SuperCollider, I get this error:
/Users/Scott/TopNFreq/source/TopNFreq.cpp:26:10: fatal error: 'SC_PlugIn.h' file not found
#include "SC_PlugIn.h"
This struck me that it meant that it still needed to reference the SuperCollider source material, so I ran the original code:
This produced a long bunch of text (let me know if it would make sense to reproduce here), finally stating that “13 warnings and 3 errors” were generated. I hoped that maybe the sc/scx files would work, when placed in /Extensions, but it still produces this error in SuperCollider’s post window:
*** ERROR: dlopen '/Users/Scott/Library/Application Support/SuperCollider/Extensions/TopNFreq/TopNFreq.scx' err 'dlopen(/Users/Scott/Library/Application Support/SuperCollider/Extensions/TopNFreq/TopNFreq.scx, 0x0002): tried: '/Users/Scott/Library/Application Support/SuperCollider/Extensions/TopNFreq/TopNFreq.scx' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e' or 'arm64')), '/System/Volumes/Preboot/Cryptexes/OS/Users/Scott/Library/Application Support/SuperCollider/Extensions/TopNFreq/TopNFreq.scx' (no such file), '/Users/Scott/Library/Application Support/SuperCollider/Extensions/TopNFreq/TopNFreq.scx' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e' or 'arm64'))'
You are using the ARM version of SuperCollider, but the plugin is compiled only for x86_64. If you are on an ARM machine, it should produce ARM plugins by default. Did you mess with the CMAKE_OSX_ARCHITECTURES option?
As a side note, you can pass -DCMAKE_OSX_ARCHITECTURES="arm64;x86_64" to create universal binaries that work on both x86_64 and ARM.
This produced a long bunch of text (let me know if it would make sense to reproduce here), finally stating that “13 warnings and 3 errors” were generated.
If CMake throws an error, you cannot expect the build to work… If you don’t post the text, we are only able to guess. If it’s too long, you can just save and upload it as a text file.
I definitely didn’t knowingly mess with the OX_Architectures option - I think the issue is that I was trying to install the pre-compiled sc/scx files that were exclusively for x86_64.
I attempted to modify the architecture per your instruction, but the compilation errors still persisted - and I suspect they are not completing the action sufficiently. I’ve attached a full report here, in case it helps. Thank you for all the help so far! fullReport.txt (44.2 KB)
You are still building SuperCollider instead of the plugin. I think at one time you have accidentally set the source directory to your SC folder, which is now still in the cache. Do the following:
delete the whole plugin folder and download it again
create a build folder inside the plugin source folder
cd into build
cmake .. <your options>
cmake --build . --config Release
The double dot tells CMake that the sources are in the parent folder. The build folder will contain all the generated CMake files, making it easy to delete them and start over if needed.
Just to save you the pain of building a plugin – what you probably want is the FluidSineFeature from the FluCoMa library, which actually gives you the top N frequencies of a signal, whereas TopNFreq gives you the top N bins (or at least it used to). The FluCoMa library has prebuilt binaries for all platforms.
Hi there -
Thanks for explaining this - I was not understanding how the syntax worked here, so I appreciate this opportunity to learn. I followed the directions you provided, but this is the resultant error:
/Users/Scott/TopNFreq/source/TopNFreq.cpp:26:10: fatal error: 'SC_PlugIn.h' file not found
#include "SC_PlugIn.h"
I am wondering if I can just find SC_PlugIn.h somewhere and copy it into the build directory?
That’s what the SC_PATH option is for: cmake .. -DSC_PATH=<your supercollider path>.
When I wrote cmake .. <your options> I meant that you should add your options that you already had. Judging from your other posts, that would probably be:
cmake .. -DSC_PATH= ~/SuperCollider -DCMAKE_BUILD_TYPE=Release (Note the double dots!)
Supercollider plugins do not link against Supercollider! All functions are provided as function pointers in a special struct called the “interface table” (see include/plugin_interface/SC_InterfaceTable.h) Every plugin exports a function called load that serves as the entry point; when SC loads a plugin, it passes the interface table to the load function.
Ah, your right, I’ve confused loading a dynamic shared object (dlopen) with dynamic linking - annoying because I akind knew that… I’m just gonna delete that post!
Yes - I definitely deleted it.
As an additional experiment, I made a new folder with a different name, copied only the sc & scx files over, ran the same script, and got the same result.
