Working on my first module here (Mac OS 10.14, Rack v1.1.15). I have been successful in developing locally but I would like to start tracking/pushing changes in my project to a private GitHub repo.
My non-git flow has been to make code changes and use Terminal to
RACK_DIR=<Rack SDK folder> make install. After setting up git in my directory, still good. However, using
git push -u origin master to my GitHub account,
make install completes the build and places it in the Rack plugins folder (visible in Finder) but removes the plugin from the Rack app module browser.
Has anyone encountered this? TYIA
There’s a lot of steps going on here. If your plugin folder is in the correct place but you don’t see your modules in the Module Browser, the log file will tell you what the loading problem is.
Ok, checking out log file now. I’m seeing the similar problem of not loading plugin after making an inconsequential change (remove character, add same character back, save file).
This appears to be relevant warning from log file (my plugin is AmenTest2):
[4.865 warn src/plugin.cpp:158] Could not load plugin /Users/inez/Documents/Rack/plugins-v1/AmenTest2: Failed to load library /Users/inez/Documents/Rack/plugins-v1/AmenTest2/plugin.dylib: dlopen(/Users/inez/Documents/Rack/plugins-v1/AmenTest2/plugin.dylib, 2): Symbol not found: _modelBaronial
Referenced from: /Users/inez/Documents/Rack/plugins-v1/AmenTest2/plugin.dylib
Expected in: flat namespace
_modelBaronial is not found, but to be clear the build works until I save.
are you sure you aren’t trying to instantiate baronial in your module?
modelBaronial sounds like a DrumKit module.
No, I am not trying to instantiate Baronial. I’ve repurposed some DrumKit code and it may be hanging around. Regardless, the module builds/installs fine with it in there until I save a trivial change.
just noting that it wouldn’t be giving you an error about that module unless it were linked into
init() via something like
if you have some source you can share, I’m happy to point to it.
obviously I don’t care that you’re using drumkit source, or I wouldn’t have licensed it the way that I did
Oh you’re THAT Jerry, haha. Yeah, I’m super green with this and needed a good starting point. I’ll email ya
Hot update: my plugin started crashing Rack! Here’s the log:
[5.136 info src/plugin.cpp:154] Loaded plugin AmenTest v1.0 from /Users/inez/Documents/Rack/plugins-v1/AmenTest
[5.150 fatal src/main.cpp:39] Fatal signal 6. Stack trace:
11: 1 Rack 0x000000010b3ae019 _ZL18fatalSignalHandleri + 41
10: 2 libsystem_platform.dylib 0x00007fff7983fb5d _sigtramp + 29
9: 3 ??? 0x00007ffee48bc250 0x0 + 140732732785232
8: 4 libsystem_c.dylib 0x00007fff796f96a6 abort + 127
7: 5 libsystem_c.dylib 0x00007fff796c220d basename_r + 0
6: 6 Rack 0x000000010b40a58d _ZN4rack6plugin6Plugin8addModelEPNS0_5ModelE + 93
5: 7 plugin.dylib 0x000000010bc1c9d7 init + 39
4: 8 Rack 0x000000010b3b4111 _ZN4rack6pluginL10loadPluginENSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIcEEEE + 1009
3: 9 Rack 0x000000010b3b35cb _ZN4rack6plugin4initEv + 1003
2: 10 Rack 0x000000010b3ad9e5 main + 949
1: 11 Rack 0x000000010b345034 start + 52
0: 12 ??? 0x0000000000000001 0x0 + 1
Is there a badge for this?
Edit: removing the plugin made Rack happy and resolved this.
haha, no, there isn’t. But now I would try gdb to see where it is crashing:
I don’t know if you are building rack. I do, so I run gdb like this, from the rack folder:
then when gdb comes up:
then when it crashes, type “bt” (for backtrace) and it will give the the stack like you posted, but with symbol names and such.
not sure why the “ugh”, I’ve typically had a better experience in lldb than I’ve had in gdb. of course, I still miss dbx, so no accounting for taste I guess.
just because it’s unfamiliar, so it takes a trip to google to figure out how to use it.
the whole llvm suite makes me sad when I have to use the gnu suite at this point. pre-egcs, the gnu suite was slow, but very easy to work with. post-egcs it was hugely improved for compilation, but much more complicated to work inside. llvm (and clang/clang++) make me nostalgic for those simple gcc days, but still compile extremely well.
if you take the time to learn lldb, it’s amazing, and quite a few of the gdb commands “just work” (those ones were old dbx commands that gdb adopted).
Thanks @jerrysv and @Squinky. Learning a lot here!