HelloWorld plugin problems installing

[CrazyZ]

Hi guys,

I have just started getting into Code::Blocks and I really want to help contribute to this by creating plugins.  So I've started with the HelloWorld plugin, which I had some trouble with because it's a bit outdated.  So as soon as I can get his first plugin working, I'm going to update it.

Anyways, I've had quite a bit of problems actually getting this thing working.  I finally got it to compile correctly, but when I go to "Manage Plugins..." and "Install New", and select my .cbplugin.  But it just says "One or more plugins were not installed successfully..."

Anyways, the little pop-up at the bottom says I should check the application log... but it doesn't tell me where this log is located at all and I can't find it anywhere.

Can you guys help me out by telling me where to find out the application log?

thanks

[Howard]

...
Anyways, the little pop-up at the bottom says I should check the application log... but it doesn't tell me where this log is located at all and I can't find it anywhere.

Can you guys help me out by telling me where to find out the application log?

thanks

If you have recently updated from svn, you may have to click menu/view/layouts/delete current.

That worked for me.

[stahta01]

The lower window with build log and build messages; right click on its title bar and see if you can turn it on.

The last few builds, I think it might have been called "Code::Blocks" under toggle option.

Tim S

[CrazyZ]

Thanks you guys so much for the quick reply.

I got this as the error message for the build:

C:\Program Files\Code Blocks/share/codeblocks/plugins/HelloWorld.dll: not loaded (missing symbols?)

Unfortunately, I don't understand what's going on because it compiled alright, so I would have though that all the symbols would have been taken care of?  I will post my code below:

Code Select Expand

#include <sdk.h> // Code::Blocks SDK
#include <configurationpanel.h>
#include "HelloWorld.h"

#include <manager.h>
#include <logmanager.h>

// Register the plugin with Code::Blocks.
// We are using an anonymous namespace so we don't litter the global one.
namespace
{
    PluginRegistrant<HelloWorld> reg(_T("HelloWorld"));
}

// constructor
HelloWorld::HelloWorld()
{
    // Make sure our resources are available.
    // In the generated boilerplate code we have no resources but when
    // we add some, it will be nice that this code is in place already ;)
    if(!Manager::LoadResource(_T("HelloWorld.zip")))
    {
        NotifyMissingFile(_T("HelloWorld.zip"));
    }
}

// destructor
HelloWorld::~HelloWorld()
{
}

void HelloWorld::OnAttach()
{
    // do whatever initialization you need for your plugin
    // NOTE: after this function, the inherited member variable
    // m_IsAttached will be TRUE...
    // You should check for it in other functions, because if it
    // is FALSE, it means that the application did *not* "load"
    // (see: does not need) this plugin...
}

void HelloWorld::OnRelease(bool appShutDown)
{
    // do de-initialization for your plugin
    // if appShutDown is true, the plugin is unloaded because Code::Blocks is being shut down,
    // which means you must not use any of the SDK Managers
    // NOTE: after this function, the inherited member variable
    // m_IsAttached will be FALSE...
}

int HelloWorld::Execute()
{
    // do your magic ;
    if( !IsAttached() )
        return -1;
    Manager::Get()->GetLogManager()->Log( _("Hello World!") );
    return 0;
}


Thanks guys again for helping out!

[MortenMacFly]

Unfortunately, I don't understand what's going on because it compiled alright, so I would have though that all the symbols would have been taken care of?  I will post my code below:

I think you are missing to provide a (zipped) manifest.xml file for the plugin (and putting it into the right place). Look at other plugins how they do that... for example the envvars plugin. Notice the post build steps and that the zip archive has to have the same name as your plugin (case sensitive on linux). Anyways... it's really simple! :-)
With regards, Morten.

[XayC]

If you are using the latest nightly build (4639) the problem may be caused by a bug. A recently applied patch (this one) broke post build commands, and they are required to correctly build a plugin.
The bug has been fixed though, so as soon as a new nightly build is out just update it and everything should work again.

Regards, XayC

[CrazyZ]

alrighty then, i suppose i'll just wait for the next nightly build.

thanks guys!

[CrazyZ]

So I got the newest nightly build, and tried to compile (successful, no error messages), and install the plugin, but I still get the following error, which is the same as the last time:

C:\Program Files\Code Blocks/share/codeblocks/plugins/HelloWorld.dll: not loaded (missing symbols?)

I'm looking at the HelloWorld.zip file that was generated in my source code directory, and it only contains the manifest.xml file; nothing else.  Do you guys know what is going on???

Thanks!

[dmoore]

It looks like you are trying to install to a downloaded cb nightly build? if so, then you need to make sure you link against the codeblocks.dll and wxmswXXXXX.dll in the nightly build and not against those in your compiled cb and wxwidgets sources.

more normal practice for building and testing your own plugins is to:
1. build wxwidgets and cb from sources yourself (build a release version of WX and a debug version of CB).
2. compile and link your plugin against those sources and their corresponding binaries (it is common C::B practice to define cb and wx global variables and use them in your project and build setttings so you don't have to hardcode paths)
3. add a post build script that copies you plugin dll and manifest to $(#cb)/devel/share/Codeblocks/[plugins/]
4. make sure that you set Project->Set program arguments to $(#cb)/devel/Codeblocks.exe with optional program arguments --personality=debug (so that you can set up environment settings that differ from your default set)
5. make sure you do NOT strip debugging symbols in your plugin build options
6. now you can run or debug your plugin from within CB.
7. to build a release version of cb (with stripped binaries) with included plugins run the update.bat script found in the CB source -- note that these binaries won't be compatible with the nightly builds.

anyway, if this is your problem then you aren't alone. plenty of new plugin developers stumble at this first step.

[XayC]

And if you want to build a plugin which can work also with the nightly builds, you have to link it to wxmsw28u_gcc_cb.dll instead of wxmsw28u_gcc_custom.dll.
The generated name for the wxWidgets dll can be selected when compiling wxWidgets, you have to add VENDOR=cb to the makefile options.

Regards, XayC.

[MortenMacFly]

you have to add VENDOR=cb to the makefile options.

You should *not* do that. This is deprecated and was the root of many issues. Just leave the vendor as it is (don't provide this for the compilation of wx).

[XayC]

You should *not* do that. This is deprecated and was the root of many issues. Just leave the vendor as it is (don't provide this for the compilation of wx).

Ah, ok :oops: good to know.
So how can I build a plugin that will correctly load with a nightly build? And how is wxWidgets built to get the wxmsw28u_gcc_cb.dll file provided with the nightly builds?

Thanks, XayC.

[dmoore]

So how can I build a plugin that will correctly load with a nightly build?

you need to make sure you link against the codeblocks.dll and wxmswXXXXX.dll in the nightly build and not against those in your compiled cb and wxwidgets sources.

you don't have to link against the .a files, you can link directly to the .dll files

And how is wxWidgets built to get the wxmsw28u_gcc_cb.dll file provided with the nightly builds?

Correct me if I'm wrong, but I imagine they do use VENDOR=cb. The point is the C::B devs are the official vendor of that wx build. When you create your own build of wx it is not necessarily compatible with the cb build so you should not give them the same name. It is far easier to diagnose the error of someone trying to run a plugin compiled against one build of a library but run against another incompatible build of that library if they don't share the same name.

[MortenMacFly]

And how is wxWidgets built to get the wxmsw28u_gcc_cb.dll file provided with the nightly builds?

Correct me if I'm wrong, but I imagine they do use VENDOR=cb.

Partially. Killerbot does but he knows exactly what he is doing. I don't and I believe Yiannis and Thomas don't, too. If you compile wx for C::B only you *can* do this but you better shouldn't. Search the forum for more information on vendor=cb.
With regards, Morten.

[mandrav]

So how can I build a plugin that will correctly load with a nightly build?

Link your plugin to the nightly's wxmsw28u_gcc_cb.dll...