Building Plugins with Code::Blocks?


#1

Is anyone here building plugins using MinGW/Code::Blocks? The basic plugin project generated by the Introjucer will build fine in Code::Blocks, but the resulting plugin is not seen by any hosts. The demo host states that the file appears to be a plugin but can not load. When exporting the symbols to a text file I see reference to "VSTPlugMain" or "main" as I do with MSVC built plugins. I'm using quite a a few MinGW built libraries in my projects, so being able to use the same compiler to build the JUCE part would make things a lot easier for me, especially in terms of debugging the other libraries. Any ideas? 


#2

If you look at the VSTPluginMain declaration, there are attributes to make it get exported - could be that it needs a mingw-specific tweak to make it work, rather than the MSVC flags that are probably being used there.


#3

I assume you're talking bout this code:


#else
    extern "C" __declspec (dllexport) AEffect* VSTPluginMain (audioMasterCallback audioMaster)
    {
        return pluginEntryPoint (audioMaster);
    }
   #ifndef JUCE_64BIT // (can't compile this on win64, but it's not needed anyway with VST2.4)
    extern "C" __declspec (dllexport) int main (audioMasterCallback audioMaster)
    {
        return (int) pluginEntryPoint (audioMaster);
    }
   #endif
#endif

I tried using '__attribute__ ((visibility ("default")))' instead of __declspec (dllexport) but the functions still don't get exported. I'm not sure why? I odn't see any MSVC specific code in there. I know atom has had some success in building projects with MinGW, perhaps he'll chime in with some suggestions. Btw the juce_VST_Wrapper isn't set to be compiled when exporting plugin projects from Code::Blocks. I had to open the Code::Blocks project and turn on the compile option for it manually. 
 


#4

I finally got this going, but in the end I had to write my own makefile. I don't think the plugin project building built by the Introjucer is setting things up right. For instance juce_VST_wrapper.cpp is not being compiled, which explains the lack of plugin export symbols in the resulting .dll! I did have to change:

extern "C" __declspec (dllexport) AEffect* main(audioMasterCallback audioMaster)

to upper-case main(). 

extern "C" __declspec (dllexport) AEffect* MAIN (audioMasterCallback audioMaster)
After that it built fine. 


#5

Well, I've never promised full support for CodeBlocks, and it's not a target that I can afford to spend much time on. If you want to suggest some tweaks to the introjucer that'd get it working, I'd be happy to look at that of course.

Strange about the upper-case main() thing, that seems bizarre to me. Maybe it's actually a macro?


#6

As lowercase I was getting an error about main() needing 0 or 2 arguments. I only thought to make it uppercase after looking through some old mingw VST source I had lying around. One other thing I forgot to mention was that I needed to comment out the following:

 #ifdef __MINGW32__
  struct MOUSEHOOKSTRUCTEX  : public MOUSEHOOKSTRUCT
  {
     DWORD mouseData;
  };

It was giving the following errors:

..\..\JuceLibraryCode\modules\juce_audio_plugin_client\VST\juce_VST_Wrapper.cpp:46:10: error: using typedef-name 'MOUSEHOOKSTRUCTEX' after 'struct'
struct MOUSEHOOKSTRUCTEX  : public MOUSEHOOKSTRUCT
^
In file included from c:\mingw-4.7.1\i686-w64-mingw32\include\windows.h:72:0,
from ..\..\JuceLibraryCode\modules\juce_audio_plugin_client\VST\juce_VST_Wrapper.cpp:43:
c:\mingw-4.7.1\i686-w64-mingw32\include\winuser.h:599:5: note: 'MOUSEHOOKSTRUCTEX' has a previous declaration here
} MOUSEHOOKSTRUCTEX,*LPMOUSEHOOKSTRUCTEX,*PMOUSEHOOKSTRUCTEX;
^


 


#7

Thanks - I think I've sorted out the mouse hook thing for you now. Not sure what to do about the "main" thing - it definitely seems wrong to make it upper-case, but if you can give me more info about exacrtly why that works, I might be able to add something to handle it.


#8

I've really no idea but it's like this in vstpluginmain.cpp from the VST SDK:


#if (TARGET_API_MAC_CARBON && __ppc__)
VST_EXPORT AEffect* main_macho (audioMasterCallback audioMaster) { return VSTPluginMain (audioMaster); }
#elif WIN32
VST_EXPORT AEffect* MAIN (audioMasterCallback audioMaster) { return VSTPluginMain (audioMaster); }
#elif BEOS
VST_EXPORT AEffect* main_plugin (audioMasterCallback audioMaster) { return VSTPluginMain (audioMaster); }
#endif
 

Thanks for looking into the mouse hook thing. Much appreciated.  

 


#9

Yes, I know, but I think you're misunderstanding why it started working when you changed that. For example, does it still work if you remove that function altogether, or rename it "foobar"? It's only there as a fallback for very old hosts that don't recognise the VSTPluginMain function, so it seems to me that renaming it as "MAIN" would have the same effect as just removing it.


#10

Ah yes, but you're making the assumption that I claim to understand any of this ;) You're right however, renaming has the exact same effect as simply removing it. And here's the kicker. I just ran it again with lowercase main() and it does build. Turns out I must have mistook that warning for an error, when most likely it was the mouse hook error that was preventing things from building...sorry for the noise! I'll try not to post for a while ;)

[tip-toeing quietly backwards from the PC....]


#11

Ah, yes.. Thought the whole thing didn't make much sense!