Push to Github Breaks My Plugin Install

Development
1

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

2

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.

3

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
 in /Users/inez/Documents/Rack/plugins-v1/AmenTest2/plugin.dylib

Apparently _modelBaronial is not found, but to be clear the build works until I save.

4

are you sure you aren’t trying to instantiate baronial in your module? modelBaronial sounds like a DrumKit module.

5

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.

6

just noting that it wouldn’t be giving you an error about that module unless it were linked into init() via something like p->addModel(modelBaronial).

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 :slight_smile:

7

Oh you’re THAT Jerry, haha. Yeah, I’m super green with this and needed a good starting point. I’ll email ya

8

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.

2 Likes
9

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:

make debug

then when gdb comes up:

r

then when it crashes, type “bt” (for backtrace) and it will give the the stack like you posted, but with symbol names and such.

1 Like
10

lldb in this case!

1 Like
11

ugh - of course.

1 Like
12

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.

13

just because it’s unfamiliar, so it takes a trip to google to figure out how to use it.

14

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).

15

Thanks @jerrysv and @Squinky. Learning a lot here!