Hi everyone. This post should ideally be logged as a Haiku issue, but I’d like to first rule out whether it is something in my use/case before I formally log it.
I’m developing binary add-ons for Medo (a new audio IIR filter in github, so constant compile/test/edit cycle), and have noticed that unless I physically delete the .so binary before I recompile, the kernel will load a cached (older) version of the addon when testing. This is very frustrating since I have to clean + jam instead of just jamming. However, this problem does not exist for the main application. This is the first time I’ve encountered the issue, and only with addons (.so files). The binary size physically changes (but not attributes) so it’s definately an issue with BeFS caching.
Before I log an issue, does anyone see anything bizarre with my usage?
How are you loading your add-ons? I guess load_add_on, but are you passing an absolute or relative path? or a MIME signature? Are you restarting the app between tests?
I don’t expect the problem to be at BFS level, what makes you think it’s there? One thing that can happen if you have the add-on already loaded and try to load it again, is that the runtime_loader can try to be smart and say “hey I already have this one”. But that would happen only if you don’t restart the application. Otherwise you should always start from a clean state.
I guess it’s possible to look at what’s happening by looking at strace output, that will log all system calls, including the calls to open() when loading the add-on from disk.
Thanks Adrian for a quick response. I’ve further narrowed it down to actually being a problem with the Jamfile not invoking the linker, even though it compiles the object. So the topic can be ignored, there is no problem with BeFS caching, the issue is that the linker step of my Jamfile doesn’t run for reasons that I still dont understand (Medo is my first jam project).