Re: [Openexr-devel] RgbaOutputFile error on MSVC2005?

[Amaan Akram]

Thanks very much Ger for taking the time to give such detailed advice. There are quite a few great pointers there for general VC++ development!

The strangest thing is that I get a top-level MSVCR80.DLL error on your precompiled DLLs in Dependency Walker. I assume there must be an issue with my computer then? or is this correct behaviour?.
Also, I am not copying any of the missing dll's in the same location as my plugin--I always use MS redistributable packages as a way of maintaining consistency across our renderfarm and user workstations.

In the meantime, I have compiled openexr x32 and x64 static libs from source and linked them from my plugin, (everything compiled using /MD, without OPENEXR_DLL) which has removed the top-level dependencies in MSVCR80.DLL, and the plugin registers and works fine.

Thanks again for your help and advice,
amaan

Nick Porcino wrote:

Thanks Ger, the advice is bang on.

In my opinion the sanest thing for you to do is to build your plugin and
EXR together into a single DLL using 

- the static options (don't set preprocessor flags to build EXR as DLL)
- MultiThreaded as the code compilation option (not MultiThreaded DLL) 
- use a single compiler. 

This will keep all your code and heap self contained, with no DLL
redistribution/registration problems.

-----Original Message-----
From: address@hidden
[mailto:address@hidden] On
Behalf Of Ger Hobbelt
Sent: Saturday, March 28, 2009 1:16 PM
To: Amaan Akram
Cc: address@hidden
Subject: Re: [Openexr-devel] RgbaOutputFile error on MSVC2005?

I see you're compiling plugins for XSI, which apparently is compiled
with a different compiler or a MSVC version BEFORE 2005. (See bottom
for note about this.)
The fact that you are missing MCVRT80.DLL in all those depends screens
is serious trouble.

Given that you're saying you've installed the 2005SP1 runtime redist
AND the fact that you're executing within a non-MSVC2005+ compiled
binary (XSI) means this issue is VERY probably due to "missing a
build-in or external manifest" file for the application.

The fast&dirty out is to compile your plugin using the static MSVC
runtime lib, BUT this can be dangerous when your plugin actually
exists of multiple DLLs which pass pointers where (and THIS is the
IMPORTANT bit here!) code in DLL A allocated data on the heap while
such memory is released in DLL B. (Such behaviour REQUIRES that such
DLLs share a single runt-time library image in memory, a feat which
won't happen when you compile statically.

Copying the MSVCR80.DLL to c:\windows\system32 or anywhere else, as
some web pages might 'advise', is killing as it will screw up your
system long term - in other words: a maintenance/support desk disaster
for you and everybody else.

The other way is to construct a manifest file for the XSI exe.

The third way, but not on Vista (or so I heard - I don't touch that
crud with a yardstick), neither on latest Microsoft Server versions,
is to 'hack it' (NOT for production systems!) by placing a copy of
your latest MCVRT80.DLL in the same directory as where your plugin DLL
resides or (more probable to work) where the XSI exe resides (BAD
choice, doing this! See above! Once you do this, you're going down!)
This is last minute, local, panic choice. Nothing less, nothing more.


To glean a bit about this 'manifest' business and others with a
problem quite similar to yours:

- the Microsoft MSDN site

-
http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/6d16ecce-
f92b-4c53-a45b-40119c4566a6/

-
http://bytes.com/groups/net/441551-net-cannot-access-msvcr80-dll-missing
-program-file

-
http://www.instant-registry-fixes.org/why-do-i-keep-receiving-msvcr80dll
-missing-errors/


Unfortunately XSI wiki is quite quiet about this and besides
references the WRONG Microsoft DLLs while mentioning MSVC.NET 2005
(which needs MS*80*.DLLs, *NOT* the MS*71*.DLLs mentioned in that Wiki
page, as those are for MSVC.NET 2003 instead):
http://softimage.wiki.softimage.com/index.php/Cpp_Compilation_(XSISDK)
And this is lacking this sort of stuff as well, alas:
http://softimage.wiki.softimage.com/index.php/Cpp_64_bit_(XSISDK)



The fact that the compiled OpenEXR sample apps work as expected,
clearly indicate this missing 'manifest' business is 99% it: the
difference here is that those applications include the proper
(auto-generated) manifest.

Either XSI doesn't need it itself as it's compiled a different
compiler, OR it is compiled using MSVC.2005 (NOT Sp1) thus resulting
in an exe with a manifest which doesn't fit YOUR needs.
So the last, and 'best' solution for calamities like these, is to make
sure you compile any plugins using the EXACT SAME compiler
(version!!!) as the manufacturer of the main app (XSI here) used.

Note that I don't know XSI - the only way I've run into them was when
they bought CAT, a plugin for 3dsmax, and let's just say my experience
with that was sufficient to make it crystal to me XSI isn't my kind of
outfit.

Anyway.
I know - and have used in the past - Autodesk provided (and provides)
a special wrapper with their SDK (separate download from their dev
website) for plugin devs who use different compilers. This came with a
nice description what was expected and what to do, allowing me to keep
my hair in the process every time (note that 'everybody frees his own
heap allocs!' rule - which is facilitated through the 3dsmax SDK.
Don't know what XSI is offering SDK-wise there.
Haven't checked lately, but you might want to ask this MSVCR80.DLL
question in the proper XSI SDK/developer forum as this is not OpenEXR
issue but an issue any dev will run into who uses one of the modern
MSVC compilers/IDEs. The path from there includes checking (and
doublechecking) what compiler the XSI folks used themselves and
switching to that - especially when you are creating plugins which you
are going to sell, as you don't want this kind of support hassle, I am
sure.



The 'downgrade' to 1.4x isn't so much a downgrade in OpenEXR is what
you did, but you apparently downgraded in compiler version used to
build the binaries as well - and that was what made it work for you.




2009/3/26 Amaan Akram <address@hidden>:
  

I have downgraded from OpenExr 1.6 to 1.40a and use the precompiled
    

libs for
  

VS2005 -- I can now output EXRs just fine.

Is there any documentation on getting 1.40a to compile 64 bit libs?

thanks
amaan

Ger Hobbelt wrote:

Hm... did you try running one or more of the test apps included in
OpenEXR - to see if those do not turn up this error? (This might be
something due to not having the right Microsoft DLLs around or
something of that nature.)

Also check your executable/DLL using the Dependency Walker tool (
http://www.dependencywalker.com/ ) to see if any DLLs are listed as
missing (red lines). (Note: some system DLLs optionally delay-load
other system DLLs, which can show up in red - the point is that none
of the non-Microsoft DLLs and the binary itself should have
_immediate_ children listed as not available in there - unless such is
intentional.)

In case of further doubt / worry, fetch the sources (which include
project files) and compile/build the libs + tools on your own system.

My 2 cents at this moment...



On Wed, Mar 25, 2009 at 4:37 PM, Amaan Akram <address@hidden>
wrote:


Hello everyone,

I am trying to use OpenEXR in a plugin that I am making for a 3D
    

software to
  

output some data to a file. I am using precompiled libs for MSVC2005
    

from
  

hebbut.net  and link IlmImf.lib and Half.lib to produce a DLL plugin.
    

For
  

reference, I am using the following code in my app

----------code starts-------------
1.   Imf::Array2D<Imf::Rgba> pixels(N+1,M+1);
2.   pixels[j][i].r    =  x[i] ;
3.   pixels[j][i].g    =  y[j] ;
4.   pixels[j][i].b    = z[i] ;
5.   Imf::RgbaOutputFile outC("c:\\exr1.exr", Imf::Header(N+1, M+1),
Imf::WRITE_RGBA);
6.   outC.setFrameBuffer (&pixels[0][0], 1, N+1);
7.   outC.writePixels (M+1);
----------code ends-------------

The above code compiles without any errors in MSVC2005 SP1.

When I take the compiled DLL in to my app, I get an error specific to
    

my
  

application, and the error says "A procedure couldn't be found in
    

library:"
  

It turns out that the error is related to line 5 in my code
    

(RgbaOut...).
  

When I don't have this line in the code, and anything my application
    

picks
  

up the DLL without errors. But as soon as this line is added, I get
    

this
  

strange error.

I am not sure if this is something related to the 3D software that I
    

am
  

using, or with my EXR output code. Has anyone else seen something
    

similar
  

happening? I'd be grateful for any pointers

many thanks,
amaan


_______________________________________________
Openexr-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/openexr-devel





_______________________________________________
Openexr-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/openexr-devel