Wojtek,
I think the problem you are hitting here is caused by the windows library loading code checking if a module (dll, etc) which has the same base file name (i.e. name excluding any path components) as the module to be loaded has already been loaded into the process address space. If a matching module is found then all the manifest, dll redirection, and dll search path stuff is ignored and a handle to the already loaded module is returned. All the VC8 onwards c runtime dlls have a routine in their initialisation code called __check_manifest. This routine attempts to check whether the dll has been loaded via the assembly/manifest mechanism and spits out the R6034 error if it thinks is has not. If you have the c runtime sources (a full install of visual studio) you can put a break point on this function and step into it to see what is happening. This routine is why trying to load the c runtime dlls outside the manifest mechanism is usually a bad idea. Roger _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wojciech Lewandowski Sent: 12 December 2007 14:42 To: OpenSceneGraph Users Subject: [SPAM] Re: [osg-users] Latest SVN: problems with Plugins without Manifests Serge, I have created a test solution for my case. It is very simple Exec which dynamically loads DLL where osgViewer is initalized nad run. It allowed me to further narrow the scenario and see where actual problem appears. See attached example. In this example Release version will run but Debug version will crash. Release version works because executable uses shared Mutlithreded DLL CRT but Debug version does not because it was built with Mutlithreaded Debug CRT which is different than OSG plugin build model. It seems that everything is ok when both application, dynamicaly loaded modules, OSG libs and plugins are build using the same code generation model which implies use of the same runtime libs. In our problematic case Apllication was actually built with multithreaded static CRT. But modules were built with Multithread DLL model. In our app I could freely change all projects to Multithread DLL / Multithread Debug DLL and then problem disappeared. On the other hand it is perfectly correct approach to build app using one environment and dynamic modules/plugins using other environment. This is how many plugin sdks work for various comercial apllications. I wonder what will happen when OSG is built using static linking. Regards, Wojtek Lewandowski ----- Original Message ----- From: Wojciech <mailto:[EMAIL PROTECTED]> Lewandowski To: OpenSceneGraph Users <mailto:[email protected]> Sent: Tuesday, December 11, 2007 4:39 PM Subject: Re: [osg-users] Latest SVN: problems with Plugins without Manifests Hi, Serge, Looks like I used the same runtime DLLs and manifest files. Manifests were taken from WinSxS and renamed to Microsoft.VC80.CRT.manifest and Microsoft.VC80.DebugCRT.manifest. Its really puzzling that plugins without manifests work when OSG libs are linked with executables but it does not work for our App when they are linked with dynamically loaded DLLs. I saw your recent submission where you reverted Cmake generation for manifest linking - before Robert puts them into SVN I actived manifest linking in my OSG solution. I gave up. Don't have time for this struggle now. Maybe will get back to this later. On many Microsoft manifest related documentation pages they state that bulids without manifests are not supported so I wouldn't expect that we may be able to resolve this issue. Thanks, Wojtek ----- Original Message ----- From: Serge Lages <mailto:[EMAIL PROTECTED]> To: [EMAIL PROTECTED] ; OpenSceneGraph Users <mailto:[email protected]> Sent: Tuesday, December 11, 2007 9:34 AM Subject: Re: [osg-users] Latest SVN: problems with Plugins without Manifests On Dec 10, 2007 9:49 PM, Wojciech Lewandowski <[EMAIL PROTECTED]> wrote: Thanks for assistance, I will further investigate it. I use XP SP2. Something that may be important here is the fact that our app loads OSG dynamically. We have our program divided into DLL components and some of these components are linked with OSG libs. Components are selected and loaded at run time based on application config. So in in this way OSG is also loaded dynamically. It used to work flawlessly till now. One more thing, I doubt its related, but these XP are Polish language version. I assume you have msvcp80d / msvcp80 / msvcr80 and msvcr80d dlls + release and debug runtime manifests stored in 3rd party binaries or somewhere else on the system path. Where tey are located ? Can you send me these files ? I guess manifest should suffice in case you use standard SP80 VS1 redist (version 8.0.50727.762) . I took my dlls from Windoiws/WinSxS redist directory because I could not find them in the folder where I got VS8 Express installed. Maybe manifest should be modified and differ somehow than the one stored in WinSxS directory ? If I made a mistake then it must have been a manifest which was wrong. Hi Wojciech, The fact that you load OSG dynamically must be the point that make it break... About the msvc*.dll, on my dev machine I use the ones located into WinSxS (without putting them into another directory), and when I redistribute an app, I put the folder joined to this mail into the main binary folder. The simpliest way to solve it is to make it optional in CMake to generate or not the manifests, I will make the change and submit it to Robert this morning. Cheers, -- Serge Lages http://www.tharsis-software.com _____ _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
