OpenEXR developer list

headers Rodrigo Urra | 1 Jul 02:53 · /exact/

_______________________________________________
Openexr-devel mailing list
Openexr-devel <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-devel

_______________________________________________
Openexr-user mailing list
Openexr-user <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-user

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

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<thmsbinder <at> 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 <at> 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:   ger <at> hobbelt.com
mobile: +31-6-11 120 978
--------------------------------------------------

Hey there.

I'm using openExr in a plugin for Maya and I'm wondering if there's a
way to "bake" the exr libraries into my plugin dll (or mll as it
happens to be called in this case) so I don't have to distribute the
openExr dll files to every user.

I've successfully compiled both the exr libraries (following the
instructions in the readme files which come with the ilmbase and
openexr packages) and my own plugin and it's working fine as long as
the exr dll:s reside in my Maya bin directory. If I remove them
however, the plugin won't load (giving the error "the specified module
could not be found" of course). This is what I want to fix, i.e. I
want to be able to load my plugin without dependencies to the exr dll
files. Is this possible?

Let me make it clear that I'm very much a noob with all the linking
and preprocessor stuff, I've had a lot of help from this mailing list
as well as Hebbut's page in order to get this far. I believe that what
I want to do is called static linking, but I'm not sure.

If anyone has Maya (or not) and want to take a look at the vc++
project I'd be happy to upload it.

Thanks for any help.

Anders Egleus wrote:
> I'm using openExr in a plugin for Maya and I'm wondering if there's a
> way to "bake" the exr libraries into my plugin dll (or mll as it
> happens to be called in this case) so I don't have to distribute the
> openExr dll files to every user.

You can do it but you'll have to build all of the EXR libs statically, 
then link against the static .lib files. This can be tricky to get right 
though.

Fortunately the only OpenEXR plugin I've written works with a standalone 
app I've written so I just bundle the EXR DLLs with it.

--

-- 
Paul Miller | paul <at> fxtech.com | www.fxtech.com | Got Tivo?

For these kinds of situations, I just build OpenEXR directly into my
project by including all of the source files.
wes

On Tue, Jul 21, 2009 at 2:41 PM, Paul Miller<paul <at> fxtech.com> wrote:
> Anders Egleus wrote:
>>
>> I'm using openExr in a plugin for Maya and I'm wondering if there's a
>> way to "bake" the exr libraries into my plugin dll (or mll as it
>> happens to be called in this case) so I don't have to distribute the
>> openExr dll files to every user.
>
> You can do it but you'll have to build all of the EXR libs statically, then
> link against the static .lib files. This can be tricky to get right though.
>
> Fortunately the only OpenEXR plugin I've written works with a standalone app
> I've written so I just bundle the EXR DLLs with it.
>
> --
> Paul Miller | paul <at> fxtech.com | www.fxtech.com | Got Tivo?
>
>
>
> _______________________________________________
> Openexr-devel mailing list
> Openexr-devel <at> nongnu.org
> http://lists.nongnu.org/mailman/listinfo/openexr-devel
>

Hey thanks paul :)

I thought about doing that, but I realized I wouldn't know where to
begin to troubleshoot if anything went wrong, so I decided to take the
path a lot of others seem to be taking (using static libraries).

It seems I haven't really gotten the hang of mailing lists so a lot of
the replies in this thread didn't make the mailing list/archive, so
I'm just sending another mail summarizing the discussion. Sorry for
the inconvenience.

2009/7/22 Anders Egleus <andersegleus <at> gmail.com>:
> Hey thanks paul :)
>
Sorry, I meant Hey thanks Wes and Paul :)

It seems I haven't really gotten the hang of mailing lists so a lot of
the replies in this thread didn't make the mailing list/archive, so
I'm just posting this to summarize the discussion (first post at the top),
since it seems like a lot of useful info if other people have the same problems.
Sorry for the inconvenience.

2009/7/21 Anders Egleus <andersegleus <at> gmail.com>:
> Hey there.
>
> I'm using openExr in a plugin for Maya and I'm wondering if there's a
> way to "bake" the exr libraries into my plugin dll (or mll as it
> happens to be called in this case) so I don't have to distribute the
> openExr dll files to every user.
>
> I've successfully compiled both the exr libraries (following the
> instructions in the readme files which come with the ilmbase and
> openexr packages) and my own plugin and it's working fine as long as
> the exr dll:s reside in my Maya bin directory. If I remove them
> however, the plugin won't load (giving the error "the specified module
> could not be found" of course). This is what I want to fix, i.e. I
> want to be able to load my plugin without dependencies to the exr dll
> files. Is this possible?
>
> Let me make it clear that I'm very much a noob with all the linking
> and preprocessor stuff, I've had a lot of help from this mailing list
> as well as Hebbut's page in order to get this far. I believe that what
> I want to do is called static linking, but I'm not sure.
>
> If anyone has Maya (or not) and want to take a look at the vc++
> project I'd be happy to upload it.
>
> Thanks for any help.
>

2009/7/21 Michael Wolf <michael.wolf <at> db-w.com>:
>
> You'd want to link with a static link library for that (unlike a DLL which is a Dynamic Link Library) . We're
using one for our exr plugin for LW which is also distributed as a single file.
>
>
> You need to change the OpenEXR project.
>
> Here's a short (and probably incomplete) description:
>
> * Open OpenEXR.sln
> * Kick out makelib
> * In the properties of: half, Iex, IlmImf, IlmThread, Imath change General->Project
Defaults->Configuration Type to Static Library(.lib)
> * In the properties of all projects, change C/C++->Code Generation->Runtime Library to a non-DLL
version (otherwise you'll still need to ship with the msvc runtime DLLs).
>
> Build
> In your Maya plugin project, also change the runtime library to a non-dll version.
> Link with the OpenEXR Libs as before.
>
> That should be it unless I forgot something...
>

2009/7/21 Paul Miller <paul <at> fxtech.com>:
>
> You can do it but you'll have to build all of the EXR libs statically, then
> link against the static .lib files. This can be tricky to get right though.
>
> Fortunately the only OpenEXR plugin I've written works with a standalone app
> I've written so I just bundle the EXR DLLs with it.
>

2009/7/21 Anders Egleus <andersegleus <at> gmail.com>:
(in reply to 2009/7/21 Michael Wolf <michael.wolf <at> db-w.com>:)
> Hi Michael!
>
> Thanks for the quick reply :)
>
> Your suggestions seem pretty straightforward and vc++ - adapted, which is
> exactly what I needed, cheers for that :)
>
> There's only one step that confuses me:
>
>> * Kick out makelib
>
> I didn't find anything in any solution with that name. I'm using the 1.6.1
> version of OpenExr and the 1.0.1 version of IlmBase.
>
> Thanks in advance.
>
> Anders.
>

2009/7/21 Michael Wolf <michael.wolf <at> db-w.com>:
>
> That may be from an older version then. Basically, if any of the .bat files that are run during the compile
screw up... disable them :)
>
> Cheers,
> Mike
>

2009/7/21 Anders Egleus <andersegleus <at> gmail.com>:
(in reply to 2009/7/21 Paul Miller <paul <at> fxtech.com>:)
> Thanks Paul :)
>
> That's my escape plan If I don't get the static linking to work, and it's
> fine to have the dlls there while I develop. I just like to keep things
> clean and slim, plus then I don't have to worry about people having the
> right dlls in the bin folder for future versions of exr.
>
>

2009/7/22 Anders Egleus <andersegleus <at> gmail.com>:
(in reply to 2009/7/21 Michael Wolf <michael.wolf <at> db-w.com>:)
> Hi again Mike.
>
>> That may be from an older version then. Basically, if any of the .bat
>> files that are run during the compile screw up... disable them :)
>
>
> Sorry for my disgraceful noobness, but  [blushing]...
>
> how do I do that?
>
>
>

2009/7/22 Michael Wolf <michael.wolf <at> db-w.com>:
> On Wed, 22 Jul 2009 00:04:39 +0200, Anders Egleus <andersegleus <at> gmail.com> wrote:
>
>
> They are usually in the properties for a project, post-build actions and the like. You can just exclude
them from the build (which, as all these settings, is for the current Configuration only, i.e.
Release/Debug etc...).
>
> Cheers,
> Mike
>

2009/7/22 Anders Egleus <andersegleus <at> gmail.com>:
> Ok, I get it now :) Thanks
>
> I compiled IlmBase statically according to your suggestions, and the
> libraries seemed to compile without errors (and the .lib files are much
> larger now) so I guess that's a good sign. The test projects didn't compile
> error free, but I guess that's to be expected, and hopefully nothing to
> worry about. So on to OpenExr and the ilmImf lib...
>
> Thanks a million for all the help, I'll let you know how it goes.
>
>

2009/7/22 Michael Wolf <michael.wolf <at> db-w.com>:
> On Wed, 22 Jul 2009 00:26:34 +0200, Anders Egleus <andersegleus <at> gmail.com> wrote:
>
> Hi Anders,
>
>
> You're welcome. And don't forget the C/C++ language->runtime library option will need to be the same for
all binaries (your plugin and the .lib files you're just creating) - otherwise you'll be bombarded with
linker errors.
>
> Cheers,
> Mike
>

2009/7/22 Anders Egleus <andersegleus <at> gmail.com>:
> Well, everything seems to be working, except I still need to distribute the
> zlib1.dll file, but I guess I could try to do a static build of that too,
> right? Do you remember if you did that too for your LW plugin?
>
> Also, the plugin is working funcionality-wise, but debugging seems not to be
> working anymore (I get "no symbols have been loaded" when I attach vc++ to
> maya and set a breakpoint). But I guess that's no problem since I should be
> able to do a static build for the release version and a dynamic build for
> the debug version as long as I'm consistent right? Like I said before, I
> don't mind distributing the dlls to myself for debugging :)
>
> Once again, many many thanks for the help, cheers :)
>
> Anders
>
>

2009/7/22 Michael Wolf <michael.wolf <at> db-w.com>:
> On Wed, 22 Jul 2009 01:05:26 +0200, Anders Egleus <andersegleus <at> gmail.com> wrote:
>
>
> Yes, It's the same procedure.
>
> You can change the debug builds to be static as well.
>
> Great to hear it's working!
>
> Cheers,
> Mike
>
>

2009/7/22 Wesley Smith <wesley.hoke <at> gmail.com>:
(in reply to 2009/7/21 Paul Miller <paul <at> fxtech.com>:)
> For these kinds of situations, I just build OpenEXR directly into my
> project by including all of the source files.
> wes
>

2009/7/22 Anders Egleus <andersegleus <at> gmail.com>:
> Hey thanks paul :)
>
> I thought about doing that, but I realized I wouldn't know where to
> begin to troubleshoot if anything went wrong, so I decided to take the
> path a lot of others seem to be taking (using static libraries).
>

2009/7/22 Anders Egleus <andersegleus <at> gmail.com>:
> Sorry, I meant Hey thanks Wes and Paul :)
>

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

6	February 2012
2	January 2012
2	November 2011
8	September 2011
12	August 2011
5	July 2011
2	June 2011
18	May 2011
15	April 2011
15	January 2011
9	November 2010
9	October 2010
6	September 2010
34	August 2010
4	June 2010
6	May 2010
31	March 2010
5	February 2010
12	December 2009
2	November 2009
2	October 2009
11	September 2009
11	July 2009
18	June 2009
4	May 2009
23	March 2009
5	February 2009
7	January 2009
4	December 2008
6	November 2008
18	October 2008
10	September 2008
11	August 2008
4	July 2008
19	June 2008
9	May 2008
8	April 2008
11	March 2008
12	February 2008
11	January 2008
30	December 2007
13	November 2007
9	October 2007
3	September 2007
26	August 2007
2	July 2007
11	June 2007
33	May 2007
11	April 2007
47	March 2007
9	February 2007
35	January 2007
49	December 2006
22	October 2006
23	September 2006
19	August 2006
17	July 2006
27	June 2006
11	May 2006
15	April 2006
29	March 2006
23	February 2006
55	January 2006
22	December 2005
17	November 2005
17	October 2005
10	September 2005
15	August 2005
48	July 2005
18	June 2005
14	May 2005
20	April 2005
91	March 2005
51	February 2005
27	January 2005
13	December 2004
54	November 2004
45	October 2004
57	September 2004
74	August 2004
17	July 2004
52	June 2004
58	May 2004
21	April 2004
35	March 2004
34	February 2004
112	January 2004
39	December 2003
31	November 2003
45	October 2003
9	September 2003
25	August 2003
25	July 2003
18	June 2003
16	May 2003
57	April 2003
116	March 2003
16	February 2003
58	January 2003
2	March 2002

Ilmbase 1.0.1 and OpenEXR 1.6.1 under Windows x64

Re: [Openexr-devel] Ilmbase 1.0.1 and OpenEXR 1.6.1 under Windows x64

R6034 with OpenEXR and Visual Studio 2008

Re: R6034 with OpenEXR and Visual Studio 2008

"baking" openExr into plugin dll

Re: "baking" openExr into plugin dll

Re: "baking" openExr into plugin dll

Re: "baking" openExr into plugin dll

Re: "baking" openExr into plugin dll

Re: "baking" openExr into plugin dll (thread discussion summary)