openexr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ger Hobbelt
Subject: Re: [Openexr-devel] RgbaOutputFile error on MSVC2005?
Date: Sat, 28 Mar 2009 21:15:39 +0100

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
>
>



-- 
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
--------------------------------------------------




reply via email to

[Prev in Thread] Current Thread [Next in Thread]