Re: [Openexr-devel] R6034 with OpenEXR and Visual Studio 2008

[Ger Hobbelt]

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<address@hidden> 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
> address@hidden
> 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:   address@hidden
mobile: +31-6-11 120 978
--------------------------------------------------