I have not run into this issue with OpenEXR itself, though I've seen it happen with different libs a couple of times; from the sound of it you already found that the usual culprit here is the Manifest Apocalypse, which is visited upon us since MS 'solved' DLL Hell for us since MSVC2005 and those adorable manifests.
So here's the questions that remain, given that you incorporate the menifest in the DLLs: 1) are you building your own binaries, which invoke OpenEXR, using the very same compiler and settings (multithreading, debug/release, that sort of thing)? If the answer is no, we've got a candidate. 2) you said you did, but I _got_ to ask: did you check explicitly that the manifest got incorporated? (I'm doing this off the top of my skull right here and now, so I'm a bit fuzzy on the next /exact/ detail, but here it is) This can be verified by opening the DLL in Visual Studio or in a tool which can dump the resources for you: each DLL should actually carry an RT_MANIFEST (fuzzy bit: it's an RT_*something* resource you got to find). I've seen it happen that mt was invoked but the manifest didn't make it into the DLL anyway; the conditions at the time are lost in the mysts of my fuzzy brain, sorry. Anayway, got to ask, as it's a real nasty, see next item: 3) Given the way OpenEXR is built, using the CreateDLL tool, #2 is a prime candidate when you didn't apply it AFTER the CreateDLL has REGENERATED the DLL: I wrote that in caps as that's what CreateDLL is actually doing under the hood: re-running the link phase with a tailored DEF/export file. In other words: if your build process turns out to be: - regular MSVC link phase - mt integrate manifest into DLL - CreateDLL invocation you MUST swap those last two (edit the post-built action, for example) or your manifest won't make it into the final DLL: that's where #2 (verification of RT_* resource existing in DLL actually used) comes up again. (And on an off note to myself: I should post my CreateDLL as it is now; the bugger has been tested a lot now on 32 and 64 bit systems and I promised I would do that about half a year back. There's a couple of changes that might interest other folks..) Anyway, closing off tonight (er, this morning): the easiest way out of this conundrum I've found is to make ab-so-lu-te-ly bloody sure e-ve-ry project [part] is built using the same compiler and project settings, including the usual suspects MT/MD/et al (multithreading yes/no, debug/release, you know the drill) but also stuff like Exception handling are important to match. And last but not least: did you check your binaries, EXE and DLLs together, with the 'depends' tool (google that one if you haven't got it yet; currently at v2.7-something if I recall correctly): that bugger should NOT list any warnings or dependency errors unless you are very sure about what you're doing (and just in case: playing the delayed loading game is assuming you're exactly that, by the way ;-) ) and check your dll's don't happen to load ever so slightly different MS RTL DLLs by /any/ chance. On Fri, Jul 17, 2009 at 7:24 PM, Thomas Binder<thmsbin...@gmail.com> wrote: > Hi, > > there are one or two threads around on this topic, they were of no > help to me so far. Here is a short description of my problem: > > Setup: > > - I want/must use OpenEXR as dll with my own Windows XP 32 bit C++ application > - I want/must use Visual Studio 2008 Standard Edition (VC9), SP1 is installed > - I took the ilmbase 1.0.1, openexr 1.6.1 source code and converted > the projects via the Visual Studio conversion wizardry > - Was able to eliminate all undefined symbols, everything compiles and > links fine. > > Problem: > > Consistent runtime error R6034 when loading OpenEXR dlls. Spelled out > R6034 means that an application or dll has attempted to load the MSVC > runtime without using a manifest. > > Indeed, my main application finds the runtime in > C:\windows\winsxs\...., which is good, while the openexr dlls are > looking in $PATH only. If I remove all MSVC*90.DLL from the path, the > openexr dlls will not load. > > Remarks: > > I used mt.exe (manifest tool, unrelated to magnetic tape) to put the > generated manifests into the dlls. Running mt works fine, and the XML > is indeed incorporated into the dll. However, this does not change > anything. Any dll is created via the createDLL linker wrapper, which I > am currently looking at. > > Your input on this issue is really appreciated. The solution may be > simple - my experience with things like this is limited. > > Thanks, > Tom > > > _______________________________________________ > Openexr-devel mailing list > Openexr-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/openexr-devel > > -- Met vriendelijke groeten / Best regards, Ger Hobbelt -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 -------------------------------------------------- _______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/openexr-devel
