Missing library when building the simulator in v2.0-dev

Plugin Development
1

I’m trying to build the simulator (from the v2.0-dev branch) but it fails with a missing library.

[962/962] Linking CXX executable simulator
FAILED: simulator 
: && /usr/bin/c++ -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.2.sdk -mmacosx-version-min=15.1 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -Wl,-map,simulator.map -L /opt/homebrew/lib -Wno-stringop-overflow CMakeFiles/simulator.dir/src/main.cc.o CMakeFiles/simulator.dir/src/ui.cc.o CMakeFiles/simulator.dir/stubs/random.cpp.o CMakeFiles/simulator.dir/stubs/memory/heap.cc.o CMakeFiles/simulator.dir/stubs/async_thread.cc.o CMakeFiles/simulator.dir/Users/twhiston/Code/metamodule/firmware/src/gui/elements/element_name.cc.o CMakeFiles/simulator.dir/Users/twhiston/Code/metamodule/firmware/src/gui/slsexport/ui_local.cc.o CMakeFiles/simulator.dir/Users/twhiston/Code/metamodule/firmware/src/gui/slsexport/prefs_menu.cc.o CMakeFiles/simulator.dir/Users/twhiston/Code/metamodule/firmware/src/gui/fonts/fonts.cc.o CMakeFiles/simulator.dir/Users/twhiston/Code/metamodule/firmware/src/gui/fonts/ttf.cc.o CMakeFiles/simulator.dir/Users/twhiston/Code/metamodule/firmware/src/fw_update/updater_proxy.cc.o CMakeFiles/simulator.dir/Users/twhiston/Code/metamodule/firmware/src/patch_play/modules_helpers.cc.o CMakeFiles/simulator.dir/Users/twhiston/Code/metamodule/firmware/src/midi/midi_router.cc.o CMakeFiles/simulator.dir/Users/twhiston/Code/metamodule/firmware/src/params/expanders.cc.o CMakeFiles/simulator.dir/Users/twhiston/Code/metamodule/firmware/src/patch_play/patch_player_catchup.cc.o CMakeFiles/simulator.dir/stubs/fattime.cc.o CMakeFiles/simulator.dir/Users/twhiston/Code/metamodule/firmware/lib/fatfs/source/ff.c.o CMakeFiles/simulator.dir/Users/twhiston/Code/metamodule/firmware/lib/fatfs/source/ffunicode.c.o CMakeFiles/simulator.dir/Users/twhiston/Code/metamodule/firmware/src/fs/fatfs/diskio.cc.o CMakeFiles/simulator.dir/Users/twhiston/Code/metamodule/firmware/src/fs/fatfs/delete_node.cc.o CMakeFiles/simulator.dir/Users/twhiston/Code/metamodule/firmware/src/fs/time_convert.cc.o CMakeFiles/simulator.dir/Users/twhiston/Code/metamodule/firmware/src/fs/general_io.cc.o CMakeFiles/simulator.dir/Users/twhiston/Code/metamodule/firmware/src/fs/asset_drive/untar.cc.o CMakeFiles/simulator.dir/Users/twhiston/Code/metamodule/firmware/src/user_settings/settings_file.cc.o CMakeFiles/simulator.dir/Users/twhiston/Code/metamodule/firmware/src/user_settings/settings_parse.cc.o CMakeFiles/simulator.dir/Users/twhiston/Code/metamodule/firmware/src/user_settings/settings_serialize.cc.o CMakeFiles/simulator.dir/Users/twhiston/Code/metamodule/firmware/coreproc_plugin/create.cc.o CMakeFiles/simulator.dir/Users/twhiston/Code/metamodule/firmware/metamodule-plugin-sdk/version.cc.o -o simulator  lvgl_drv/liblvglsdl.a  patch-serial/libmetamodule-patch-serial.a  -lSDL2  ui/libui.a  -Xlinker -force_load -Xlinker CoreModules-4ms/libCoreModules-4ms.a  -Xlinker -force_load -Xlinker vcv_plugin/vcv_plugin_internal/libvcv_plugin_internal.a  -Xlinker -force_load -Xlinker vcv_plugin/vcv_plugin_export/libvcv_plugin_export.a  -Xlinker -force_load -Xlinker vcv_ports/lib_vcv_ports_internal.a  vcv_ports/glue/Befaco/libBefacoLibrary.a  vcv_ports/glue/Valley/libValleyLibrary.a  -lCMSISDSP  patch-serial/libmetamodule-patch-serial.a  patch-serial/ryml/rapidyaml/libryml.a  CoreModules/libCoreModules.a  lib/liblvgl.a  cpputil/libcpputil.a  -Xlinker -force_load -Xlinker vcv_plugin/vcv_plugin_export/jansson/libjansson.a  -Xlinker -force_load -Xlinker vcv_plugin/vcv_plugin_export/pffft/libpffft.a  -Xlinker -force_load -Xlinker vcv_plugin/vcv_plugin_export/nanovg/libnanovg.a && :
ld: warning: ignoring duplicate libraries: 'patch-serial/libmetamodule-patch-serial.a'
ld: library 'CMSISDSP' not found
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.

I think I have followed the install information properly, but maybe something has changed with the v2? Maybe I’ve just done something stupid!

2

Looks like you can install it here fwiw: https://pypi.org/project/cmsisdsp/

3

Thanks that pointed me towards the library on github GitHub - ARM-software/CMSIS-DSP: CMSIS-DSP embedded compute library for Cortex-M and Cortex-A

I think I have bigger problems actually as I’m having troubles getting anything to build on the dev branch atm. Can’t even get the plugin examples to compile :man_facepalming:

4

did you do a recursive pull on git to get all the submodules?
(after checkout of branch)

git submodule update --init --recursive

I’ve not built 2.0-dev but last time I built the firmware everything that was required for build was linked as a submodule.

are you able to build/run the released branch?
I would always do that before attempting to build a dev branch… as its more likely something is missing/not updated/incomplete on a dev branch.

5

I did! I definitely double checked that. Funnily enough I can get my own plugins building on v2.0-dev but I can’t build all the examples, and can’t build the simulator, so there’s something odd going on. At least I can start working on my own code though :sweat_smile:

I will probably try to build the current stable branch next but I really want to target the dev branch because of some of the new sdk features which I need.

1 Like
6

Sorry about that! I added this library for optimizing Oneiroi, and forgot to add it to the simulator cmake.

I just pushed the fix to the v2.0-dev branch.

1 Like
7

Thanks so much Dan, that’s all working now :slight_smile:

8

@danngreen since pulling your most recent commits in the sdk, base etc… and rebuilding my plugins I now get a failure on the MM when trying to load them which says there is no init function. There is definitely an init function and they work in VCV rack locally so any idea what might have happened to cause this? They were working yesterday!
Thanks very much.

9

Can confirm that if I roll back the SDK to 1408eb9 they are loaded correctly again. Life on the bleeding edge :sweat_smile:

10

Ah, oops. The init function needs to be declared extern "C". I just made that change to the SDK (it’s the latest commit).
Life on the bleeding edge, indeed!

Are you building a native plugin, or using the Rack adaptor? If the file that defines the init function also includes <rack.hpp> then as long as the init function is void init(rack::Plugin::plugin *), it should automatically be extern “C” because rack.hpp pulls in plugin/callbacks.hh which declares that function extern “C” (here: metamodule-rack-interface/include/plugin/callbacks.hpp at bb57c0d5c85d26e7014e924c6ee21a2c0144dfc2 · 4ms/metamodule-rack-interface · GitHub)

But if your init function has a different signature (like just plain void init()) then you’ll need to declare it extern C yourself.
I probably will make this work without needing extern "C", by having firmware look for the mangled symbol name (the only point of extern C in this case is to bypass the C++ symbol mangling)

11

I’m using the rack adapter. I actually used the vcv helper.py createplugin command to make the initial files, so the init function signature is

void init(Plugin *p)

and I can see the header is pulling in <rack.hpp> so it should be extern already I think.

I got it working again by commenting out the changes you made from line 79 of plugin.cmake

    # target_compile_options(${LIB_NAME} PRIVATE
    #     -fvisibility=hidden
    #     -fvisibility-inlines-hidden
    # )

but not line 89 where you require init to be defined.

12

Oh also is there a trick to getting your plugins autoloaded? Even if I set them to autoload in the menu they never do!

13

Ok, so sounds like for some reason the linker was not making the init symbol visible.
I played with those linker flags a lot, and it seemed like the --require-defined=init flag was forcing it to export the symbol, though perhaps not…

Can you share your plugin’s CMakeLists.txt file?

The lines you commented out speed up function calls from within the plugin, and also make plugin loading faster. So it’s OK to have those off.

You’re using arm-gcc v12.2 or 12.3?

Ah, yes you need to put the version in the plugin name. So:

Pluginname-v2.0.0-dev10.3.mmplugin

The autoloader assumes a plugin with no version in the name, is v1.x, so it skips that on the v2.0 branch.

14

One more thing: I just pushed a change on the v2.0-dev branch of the SDK to add default visibility to the init() function. Can you pull and see if that fixes it for you (you’ll need to uncomment those lines about visibility in the plugin.cmake)