On May 30, 2011, at 10:37 AM, William Kyngesburye wrote: >> grassprovider.cpp was linked into both the library and the provider. Now >> it's >> only in the provider and the provider is also linked to the plugin as it >> needs >> some methods from the provider. >> >> What's the problem on mac with that? > > It just seems logically and organizationally wrong: providers and plugins are > modules that QGIS loads, not libraries that the system linker loads as > required by binaries. If all of the grass provider was in the library > before, why not just leave it only in the library instead and drop the > provider? Is there a requirement to have a provider? Otherwise, move the > provider to lib/. > > The Mac issue is that the install processing adjusts the internal linking > paths for the Mac app package organization. It does all *.so files in > plugins and *.dylib files in lib, so I'll have to make a special case to do > the one *.dylib in the plugins folder.
Is the provider as a library (linked by the plugin) meant to be *also* loaded as a module? Maybe some initialization that happens as a module but not as a library? If that's the case, there is another problem: the plugin loading code only loads .so files, even on OS X (.so is the standard module extension for OS X), and libraries on OS X are .dylib, so it will not be loaded as a module. ----- William Kyngesburye <kyngchaos*at*kyngchaos*dot*com> http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
