On 19.10.2011 22:39, Sascha Zelzer wrote: > Hi, > > your application loads liborg_blueberry_osgi.dll twice. The first time, > the Windows library loader loads it from "bin/" due to the linker > dependency of your executable to it. This initializes the > berry::InternalPlatform singleton and a Poco::Util::Application instance > with the static variable _pInstance in the PocoFoundation.dll . > > Then the plug-ins referenced in your provisioning files are installed > and started, which includes the bin/plugins/liborg_blueberry_osgi.dll > plug-in. Since it is loaded with an absolute path via LoadLibrary(...), > it is loaded a second time (you can see all loaded modules (DLLs) in > Visual Studio in the "Modules" view from the Debug menu). This creates > another berry::InternalPlatform singleton which tries to instantiate a > seconde Poco::Util::Application and fails due to the shared static > _pInstance in PocoFoundation.dll . > > The reason why a MITK Installer works without batch files is a special > handling of liborg_blueberry_osgi during provisioning, if the > .provisioning file contains the @EXECUTABLE_DIR keyword (see > berryProvisioningInfo.cpp for details). > > So in essence, duplicating plug-ins leads to faulty behavior. Please > note that you would only need a PATH entry to the plug-ins directory > containing liborg_blueberry_osgi.dll due to the linker dependency of > your executable. All plug-in directories are actually added to the > current process PATH environment variable during startup.
Hi Sascha, thank you, ommitting the copy step helped. But i am rather puzzled, because why should the app have a dependency to a delay loaded lib? Does it use the microsoft delay load feature that uses the import lib under Windows? In the code, i can see that the program relies on the qt pluguin mechanism.. Or is this wrong for my ExtApp? Is there a reason for this dependency and/or a way to circumvent that behaviour? Its the only reason in the complete build why we need the batch files: to adjust the paths for debug and release. With the old blueberry method, there was no dependency and we could deposit all binaries in our /bin directory and thus work with the several project configurations in Visual Studio seamlessly. You mentioned that the plugin path direcotries are added during runtime, as qt does. Can't the liborg_blueberry_osgi.dll also be found in the subdirectory? Regards, Thomas ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ mitk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mitk-users
