Did you verify that the OpenEXR projects and your own /all/ use exactly the same microsoft run-time environment? (project Properties > C/C++ > Code Generation > Run-time library (and the other entries, though some of those others may vary without causing trouble. That is, when you "know what you are doing" there. ;-) The 'easy way out' is making sure all code is built with exactly the same settings: leads to less to worry about.)
And platform (so you're not trying to mix, say, OpenEXR dll's which are built for a Win32 target while your own own projects build for a Win64 (amd64) target at the same time? (MSVC: Build mnenu > Configuration Manager > all listed 'Platform's must be identical for each setup, except CreateDLL, eLUT and toFloat, which will always show up as 'Win32' in there. Also make sure the listed 'Configuration's are identical for all: debug or release) Generally, the errors you mention are due to projects/libraries/dll collections which all dream their own flavor of run-time/platform dream and then brutally clash with harsh reality. It /may/ be that the Half.dll (which shouldn't be needed if the entire build (solution/.sln) is set up to create a static build of everything, including OpenEXR) isn't in the same directory as the final binary (.exe)? I haven't had time to check the latest OpenEXR release (or CVS HEAD) yet, hence this somewhat vague response; I haven't checked the latest&greatest re 64-bit compiles; there were a few surprises to be had in older releases, but given the latest intel on this ML I'd expect a hassle-free x64 build for the latest release. Also be aware that MSVC sometimes screws things up, especially when you go around and change project settings. A 'make clean' (a.k.a. 'rebuild all') may be in order to make odd behaviour magically disappear. I've had a few agonizing searches like that myself in the past, and I'm sure MSVC is still lurking in the grass for a surprise attack once I'm slacking off. MSVCR90.dll makes me assume you're using MSVC2008. Correct? (If not, then you must be using some precompiled binaries (dlls/libs) from somewhere else. Or...) On Sun, Aug 1, 2010 at 7:33 PM, Priyamvad Deshmukh <priyam...@gmail.com>wrote: > ilmbase 1.0.1 > openexr 1.6.1 > > ok, so I've spent a day trying to get this working with my code but I've > run into brick walls with each method. > Here is what I have tried until now: > 1) I tried following the readme steps exactly and they compile > successfully. > 2) When I try to use some half structures in my own code however, I get > linker errors which people have talked about elsewhere: > unresolved external symbol "private: static unsigned short const * const > half::_eLut" (?_e...@half@@0QBGB) > > The solution to it seems to be to define OPENEXR_DLL in your preprocessor > directive which indeed makes the error go away. > 3) However, I now get a runtime error saying Half.dll not found even though > I have set it up so that it looks in the Deploy/bin directory. > 4) So I try copying the Half.dll in system64 directory and now I get a > missing MSVCR90.dll error which I don't see anywhere. > > 5) I tried statically building the libraries and even though that compiles, > my application still seems to look for Half.dll. > > Anyone have any idea what is going on with this build? > Any help would be appreciated! > Aargh > Priyamvad > > _______________________________________________ > 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
