Hello
I'm struggling a bit with getting the linker going in a nodeset as far as I understand.
The nodes compile fine without complaint from both Clang and GCC until I run them in Vuo. Then i get an error:
Undefined symbols for architecture x86_64: "_ffclos", referenced from: _display_fits_image in composite...
... clang: error: linker command failed with exit code 1 (use -v to see invocation)
Dependencies are set in the description, locations are added in CMake, but I guess I'm doing something wrong or have put something in the wrong place.
In my CMake file, I have this:
... COMMAND ${VUO_FRAMEWORK}/../vuo-compile "${PROJECT_SOURCE_DIR}/${source}" --target ${arch}-apple-macos10.12.0 --output ${bitcode} --library-search-path /usr/local/Cellar/cfitsio/4.2.0/lib //where the library resides OUTPUT ${bitcode}
(there is no comment in the real CMake.txt)
My metadata contains:
"dependencies": ["cfitsio.dylib", ...] (path is /usr/local/Cellar/cfitsio/4.2.0/lib/libcfitsio.dylib)
What might I do to fix this issue?
Comments
If all you want to do is run
If all you want to do is run compositions that use cfitsio nodes on your own computer, then the fix is simple — just copy
libcfitsio.dylib
to the User Modules folder alongside your node classes. Attached is an example project that demonstrates.When you run a composition in the Vuo editor, Vuo compiles and links the composition. As you noted, it's the linking step that fails (undefined symbols). The Vuo editor has certain predetermined places where it looks for libraries, including the User Modules folder.
The
--library-search-path
argument that you mentioned comes into play when you use thevuo-link
command-line tool to link a composition. If you were to create a composition that uses your cfitsio node, and then compile and link it on the command line, the commands would look like this:If you plan to use cfitsio nodes/compositions on other computers, then it gets more complicated. If you have control over the other computer and can install libcfitsio and rebuild the node classes on that computer, that would probably be the simplest option. When building stuff on one computer and running it on another, you get into multi-architecture builds (Intel + Apple Silicon), dylib install names, and macOS Gatekeeper. I can try to help if you start down that route and get stuck.
example-cfitsio.zip
Thanks Jaymie! Having an
Thanks Jaymie! Having an easily transferrable solution would be the ideal solution, as in having it as a nodeset to just pop over to different computers. There might be a middle ground if its only a matter of the library being installed to the same location that requires rebuilding. I'm using Homebrew to install the libraries, so both cfitsio and eventual other libraries installed using that should always reside at /usr/local/Cellar if not changed by the end user.
Cfitsio is at least mulit-platform and supported on Apple Silicon, so hopefully it isn't the worst of libraries to try to include
Yeah, installing the library
Yeah, installing the library on the other computer with Homebrew might simplify things. (Though keep in mind that Homebrew installs to
/opt/homebrew/Cellar
by default on ARM instead of/usr/local/Cellar
.)In any case, I look forward to seeing your progress and how you use the nodes, if you'd like to share :)
Aha! Could the /usr/***
Aha! Could the /usr/***/Cellar be dependant on architecture in the cmake file perhaps?
I also have to admit to using some performance enhancers for this experiment (chatGPT), but as it compiles fine, and it is the linker that is complaining, I think it has been coaxed into providing something that should run at least.
Using the example you provided, I got a little bit farther. I did not get an error when running your example node, but this one still spits out a linker error:
C code for the node:
Relevant part of CMakeLists.txt:
With the code you posted, I
With the code you posted, I tried to reproduce the "undefined symbols" error, but it didn't happen for me. When I built the CMake project and used the resulting node class in a composition, I was able to run the composition without any linker errors.
Are you still building the project and running the composition on the same computer? Or does this only happen when running on a different computer?
One thing I noticed when building your project was that the last part of your CMakeLists.txt —
— refers to
${installedNode}
instead of${nodeset}
. So when you modify your node class code and runmake
, it may not be updating the node set installed in User Modules. That wouldn't directly cause the linker error, but it could lead to confusing results in general.Yeah, something like: