Well OpenEXR won't even build without /OPT:NOREF, however all other libraries I
use build and work fine with the opposite /OPT:REF. MSDN mentions /Gy is
related to this option. Do I need /Gy enabled for OpenEXR? I did have it
disabled and it gives no build errors; never used it to build any other
libraries either.
-----Original Message-----
From: Ger Hobbelt <[EMAIL PROTECTED]>
Date: Sat, 18 Oct 2008 03:35:28
To: Borislav Trifonov<[EMAIL PROTECTED]>
Cc: <openexr-devel@nongnu.org>
Subject: Re: [Openexr-devel] Pulling my hair out: switching project to VS2008
breaks OpenEXR :(
Okay, first off, I haven't been working with VS2008 in combination
with OpenEXR yet, so all this is a 'long shot'. Consider it my general
approach to stuff like this, irrespective of [MSVC/compiler] version.
I'm off line tomorrow, so can't do a quick turn-around on this. Hence
here it's all in one bang, riding the hunch:
Off hand question before I start:
> that findChannel() shows the channel is there. With a debug build it sort
> of works and sometimes doesn't... I haven't changed any of the code nor the
You mean 'sometimes' in terms of run-time: 'sometimes this executable
works when I run it, sometimes the /very same one/ doesn't' or
compile-time: 'sometimes I compile this into an executable and it
works, and sometimes I compile+link and it doesn't'? Where in the
latter case there's yet another difference: recompiling/linking
without changing /any/ settings in your projects or solution OR
recompiling/linking after changing one or more (little) items in a
project, projects or solution.
Why the question: in case of answering any of the latter scenarios
mentioned, there are a few things the truly paranoid (like me ;-) )
need to attend, as /sometimes/ merely clicking 'rebuild' isn't good
enough. The procedure below is for just that. When the answer is
'yes' to the very first option, the procedure below might still help
you, but 80/20 success/failure guestimate becomes 20/80 then.
Nevertheless, /much/ better than pulling hair as you still have the
20. Unless someone else has a much better idea...
--------------
Which leads to my 'general approach to shit hits this-type-of-fan'.
Please read through completely before starting to act on it. When
acting on it, please try to follow through as much as possible. It'll
feel like a lot of work and overdone discipline but 'winging it' is
the same as not doing it at all:
Before starting with this: backup sources and vcproj/sln/etc. files.
Better safe than sorry.
Now how I start with stuff like this:
Stage 1:
When you doubt your executables, as you do right now, you should doubt
any intermediate produce as well.
That means that 'click on rebuild' is /not/ enough. At least all
versions up to VS2005 keep some litter around at the worst possible
times. I have been bitten enough times to show the scars.
So that means: when you are in a situation like this, and you cannot
trust your development environment completely anymore for whatever
reason, the way /before/ any rebuilding is this:
a) close the solution. (this is to ensure any [network] file locks
MSVC IDE might have on stuff is gone)
b) Delete /everything/ that is not source code, .rc file or
vcproj/sln. Especially blow away any .suo, .ncb or .user files.
It is left without saying that you of course delete the entire
object/build directories. Depending on project settings those are
./debug, ./release or ./Win32/debug, ./Win32/release or (in my case)
./Win32_debug, ./Win32_release, etc.. Any directory with a lot of .obj
and/or .sbr files is 'delete' fodder.
c) It might be useful to make an extra backup of this squeaky clean
situation, so you can re-use it (with care) for retries.
d) open the solution (yes, things like 'opened files' and such are
forgotten as you blasted the .suo and .user files) and 'rebuild'.
Test binaries (prayer wheels not included).
Stage 2:
When this doesn't take care of business (I give you only a 20% chance
you got lucky already), there's the next round, which will require the
above every time again, just to be sure we start with a clean slate
/every/ time.
Since I am oldfashioned, I think of /LTCG as an 'optimization' and
right now, it's time to (a) make sure all projects for this product
are 'in sync' settingswise and (b) it's time to ditch any
'optimization smarts' as well, because we need to establish a
reference point: a [set of] binaries which work as expected.
So, after cleaning again, open the solution, select /all/ projects in
the solution and open the properties dialog. Any item in there for
compiler or linker which are not 'in tune' with all the other
projects, will be shown as blank. (if you have /library/ projects, you
won't see either the librarian or the linker tab, so to 'sync' the
librarians and the linkers you'll need two more rounds of this, as
right now you /can/ 'sync' all compiler settings)
The point of this exercise is to select 'all platforms' and 'all
configurations' and then go through the compiler settings (and linker
settings, and librarian settings if you have static library projects
in there) and manually set all options to the most bare-bones,
no-header caching/precompiling, no code-optimizing,
no-smarts-what-so-ever settings. Do not mind that you are 'changing'
your project settings all this much: you have your backups and you can
text-diff those sln and vcproj files (may I advise to use Scooter
software's Beyond Compare - my tool of choice this last decade) and
get back to where you once were.
Then when you have traveled the lot, enable debugging output (just
'/Zi' Program Database, but /not/ the 'build and continue' /ZI
flavor!) for your debug configuration (still keep 'all platforms'
selected in that dialog, just change from 'all configurations' to
'Debug configuration') and no debug output for your release project.
VERY important in the linker is this: make sure all configurations
/always/ have '/OPT:NOREF' (Keep Unreferenced Data) picked. Because if
you don't, OpenEXR and anything else DLL-ish is /toast/. The
explanation will turn this into a book instead of a top-of-mind essay,
so I'll skip that for now, just remember that little linker option can
be fatal when not configured like that. Often it will show 'default'
there - this time around, we're on the edge and at zero trust, so we
make darn sure by setting the linker option explicitly to 'Keep
Unreferenced Data' for all our projects.
Turn OFF /LTCG and other smarts as well in the linker, as you already
did as well in the compiler, and rebuild the whole bloody lot.
Stage 3:
Depending on your 'hunch'/mood, this should have gone before stage 2.
As I said I'm quite paranoid, so I always do this before Stage 2
whenever possible.
If you link-include .lib files (either static libs or .lib exports for
DLLs) for which you also have MSVC source code+project files
available, ditch them and include the projects themselves, while
making sure that the 'Dependencies' are properly ticked for each of
your projects: MSVC will automatically build these in the proper order
(of course you gave them a Stage 1 cleaning first ;-) ) and include
the necessary .lib files for you, as long as all the projects as
bundled together in that one solution.
Stage 4:
I hope you don't have to go here, but I've met a few scenarios where
it is necessary: inspection of your .vcproj files with a text editor.
This is especially important when the .vcproj files were not created
in your particular version of MSVC, but 'migrated' from earlier
versions.
To do this, make sure you have closed the solution in your IDE to
prevent file locks from screwing you over.
Next, open all vcproj files in a text editor and look for this line:
InheritedPropertySheets=...
kill them all.
Open the solution again and select all projects, then 'all platforms'
and 'release' and after than same for 'debug' config and scan through
the compiler and linker settings to make sure everything is set as you
want it to be.
Second substage here is to nuke all the hardcoded paths in the vcproj
files (after closing the solution again of course): there are a lot of
lines in there which carry 'derived' but hardcoded paths like ./Debug/
and ./Release and those can all be removed; upon reloading the
solution and projects, MSVC will correct such 'missing' entries
automatically.
Only the <Configuration OutputDirectory= and IntermediateDirectory=
lines should remain.
For comparison, download the official OpenEXR distro and the one
presented at www.hebbut.net and compare those .vcproj files and see
that I blew away all hardcoded paths (for VS2005) in there. These
days, I always do that before initial build as there's been too much
trouble with those, especially in environments where you don't only
have Debug and Release config but, say, extra 'Debug2' and 'Release2'
project configurations as well.
Also note the lines
OutputDirectory="$(ProjectName)_$(PlatformName)_$(ConfigurationName)"
IntermediateDirectory="$(ProjectName)_$(PlatformName)_$(ConfigurationName)"
in the www.hebbut.net vbcproj files: no hardcoded paths there. By the
way, if you also delete these lines, MSVC will (probably) fill in a
default like
OutputDirectory="$(PlatformName)/$(ConfigurationName)"
IntermediateDirectory="$(PlatformName)/$(ConfigurationName)"
which is kinda okay, as long as there's only one .vcproj in each
directory - which isn't always true.
Extras:
doublechecks on run-time libraries used throughout: this should have
been checked when you scan through the common project compiler and
linker settings.
Same for platform.
Last bit to make sure of: check in your 'Configuration Manager' that
each configuration+platform has checked /all/ projects /with/ the
proper platform and config settings. Go through the complete list.
Caveat here: always build the OpenEXR tools in your native platform
mode for /any/ configuration. I always have CreateDLL, eFloat and eLUT
build in Win32 mode; see the www.hebbut.net project+solution files is
you're still stuck to see what I changed in the OutputDirectories for
those as well and the post-build scripts to make sure eFloat and eLUT
are run no matter what platform you build for -- while running those
tools in Win32 platform mode at the same time.
I hope you don't have to go that far, alas.
When you have a working situation, create a backup so you can run back to it.
Extra if there's a little time left (never ;-) ):
then slowly increase the optimization/smarts in the projects, all at
the same time, and retry/test, ad nauseam. When you are back at a
sufficiently optimized, yet still working sloution/project set, you
might want to take out Beyond Compare (or another text diff/merge
tool) and compare those vcproj files with the ones from before the
very first backup when stuff didn't work yet and you started this
procedure. Check the differences and when you are not under deadline
anymore, check each of them out to find what bit you. This for when
you are the curious type. ;-)
-------------------------
I hope this helps resolve the issue you have. It is either this or
something wicked but silent with the C++ language in VS2008 (or
something I missed entirely).
Most important if you are not desperate enough yet to do the above
(for me it's easy as it has grown into a fast standard process
whenever I get someones' projects: using Beyond Compare, I always sync
them to the current 'generic' project template to make sure I don't
get surprises where I don't like 'em): check the /OPT:NOREF setting
for all your linker sections first. Without it, CreateDLL /can/
produce DLLs with just a few missing exports and they will bite you at
unexpected times like these.
Best of luck,
Ger
On Fri, Oct 17, 2008 at 11:06 PM, Borislav Trifonov <[EMAIL PROTECTED]> wrote:
> I was moving my projects from Visual Studio 2005 to 2008. Since I had built
> all my libraries with link time code generation, I had to rebuild everything
> since VS2008 wouldn't take the old binaries. OpenEXR now now longer works,
> despite me trying all sorts of changes of compiler options etc. In my
> project, with a release build FrameBuffer::insert() fails despite the fact
> that findChannel() shows the channel is there. With a debug build it sort
> of works and sometimes doesn't... I haven't changed any of the code nor the
> .exr images I'm loading. A few libraries I had been using, such as libpng
> and SDL, I built the updated versions of. But I don't see how that would
> affect anything. I'm under a deadline so I really need to get this
> resolved, but I haven't the faintest clue where to even start looking...
>
> _______________________________________________
> 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: [EMAIL PROTECTED]
mobile: +31-6-11 120 978
--------------------------------------------------
_______________________________________________
Openexr-devel mailing list
Openexr-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-devel
