How to fix your plug-in DLL

How to fix your plug-in DLL

Always look carefully at the given error message first! Only if you cannot deduce the problem from the error message, try to fix it with the hints below.

When your plug-in cannot be loaded by the BlueBerry OSGi framework, this usually indicates a problem with your DLL (and not the framework itself). You can go through the check-list below to better diagnose your problem.

If you want to contribute something (the implementation of an interface) via an extension-point (for example contributing a View to the workbench), you should check these points first:

1. Check your meta-data. Have a look at your plugin.xml file and check that your XML syntax is correct (look at the reference documentation of the extension-point you are implementing). Implementation classes given as attributes must be fully-qualified (for example class="berry::MyViewImplementation"). Note that the framework looks at the meta-data in your binary tree, so make sure the plugin.xml and META-INF/MANIFEST.MF files are up-to-date (which is normally taken care of by CMake during configuring, but if you change your meta-data in your source tree without running cmake again, the files will not be synchronized with the binary tree).
2. Check your manifest.cpp file. The argument to the POCO_EXPORT_CLASS macro must match the class-name in your plug-in XML file (i.e. POCO_EXPORT_CLASS(berry::MyViewImplementation) ).

Supposing that your meta-data is correct, check the following points:

1. (Linux only) The Linux linker usually resolves the symbols in your shared object lazily, which leads to runtime errors if some symbols cannot be found. Check with "ldd -r <path-to-your-library>" if there are any unresolved symbols. If yes, fix them (you can demangle the symbol-names with "c++filt <symbol>".
2. (Windows only) Try to load your DLL with Dependency Walker and see if there are errors.
3. You may have run into the static initialization order fiasco. Read more about it here.