Plugins that depend on other plugins?

pmax · Post by **pmax** » Sat Aug 23, 2008 5:28 pm

Dear all,

I've run into a little problem with plugins. My plugin is for adding a different GLSupport implementation to the GL RenderSystem. I patched my working copy so that is possible on the render system side. I've mentioned this problem here already, but I thought, since it is a general problem, I'd ask in a more general thread.

My problem is that when I build the plugin separately, some symbols are not defined (e.g. Ogre::GLSupport, the base class). This is easy to circumvent at compile time with "-undefined dynamic_load" (at least on OSX which I am using). On Linux, allowing undefined symbols in shared libs seems to be the default.
However, even if I have already loaded the RenderSystem_GL plugin in the final program during runtime, which defines GLSupport, etc, the dynamic library loader still complains about the missing symbols when I load the second plugin. So, the loaded symbols don't seem to propagate to the main program.

Does anyone know how to deal with this problem? Should I add specific plugin loading capability directly to the GL RenderSystem?

Thanks for your help!

Edit: PS: The exact error I get when trying to load the plugin:

Code: Select all

*-*-* OGRE Initialising
*-*-* Version 1.4.9 (Eihort)
Loading library RenderSystem_GL
Installing plugin: GL RenderSystem
OpenGL Rendering Subsystem created.
Plugin successfully installed
Loading library QtGLPlugin
2008-08-23 15:20:22.428 demo[3951] CFLog (21): Error loading /Library/Frameworks/Ogre.framework/Resources/QtGLPlugin.bundle/Contents/MacOS/QtGLPlugin:  error code 4, error number 0 (Symbol not found: __ZN4Ogre9GLSupport20initialiseExtensionsEv
  Referenced from: /Library/Frameworks/Ogre.framework/Resources/QtGLPlugin.bundle/Contents/MacOS/QtGLPlugin
  Expected in: dynamic lookup
)
terminate called after throwing an instance of 'Ogre::InternalErrorException'
  what():  OGRE EXCEPTION(7:InternalErrorException): Could not load dynamic library QtGLPlugin.  System Error: Unknown Error in DynLib::load at /Users/max/Desktop/ogre/Mac/Ogre/../../OgreMain/src/OgreDynLib.cpp (line 80)
Abort trap

pmax · Post by **pmax** » Sat Aug 23, 2008 9:27 pm

Okay, I found out what was wrong.

Basically, OSX knows two different kind of dynamically loadable code, libraries and plugins. Libraries (frameworks and dylibs) may be used to resolve symbols at runtime, plugins (bundles, the kind used for Ogre plugins like RenderSystem_GL) may not. So, the symbols I needed in the second plugin weren't available because of this distinction. Apparently this is to prevent the accidental use of third party dynamically loaded code.

I relinked the RenderSystem_GL bundle as a dylib (choose "Dynamic Library" as "Mach-O Type" in the "Build" tab of the dialog you get if you select the "GL Render System" target and press Command-i in XCode), and now the symbols get resolved properly. Funnily, contrary to some statements in the internets, the dylib code can still be loaded with CFBundleLoadExecutable.

Maybe all plugins should be compiled as dynamic libraries for this reason? I'm not sure.

Post by **sinbad** » Sun Aug 24, 2008 3:08 pm

Hmm, I'm still a relative novice on Mac and wasn't aware of this distinction. Usually of course, you don't link to plugin-specific symbols so this is not necessary, although on other platforms it is possible to link to the plugins.

Are there any other effects of changing this option? Any documentation I can read on it you can link?

pmax · Post by **pmax** » Tue Aug 26, 2008 9:26 am

It was quite hard to find this information in the first place. I dug through the GCC man pages as well as googled a lot. There are mainly two references.

The Fink Project has information about porting to Mac OSX, especially about bundles vs. dylibs:
http://www.finkproject.org/doc/porting/ ... ib-and-mod

This thread is supposed to explain the difference between bundles and dylibs, but doesn't quite manage.
http://lists.apple.com/archives/Darwin- ... 00497.html

In the end, I knew Qt compiles its plugins as dylibs. You can find that out by compiling the Plug'n'Paint example and running "otool -hv" on the library file.

I also read somewhere (I can't remember where), that the bundle type protects its symbols. This makes sense if its function is to be a plugin. As the Fink documentation says, it can be unloaded, unlike dylibs. If in the meantime, other plugins were able to dynamically link to those to-be-unloaded symbols, it would be bad.

In the end, I only know that it works. It doesn't seem to have sideeffects other than the ones described above. Since the mac implementation of DynLib doesn't unload anyway, there should be no problem.

Cheers,
max