Dear all,
for the sake of completeness some more of my findings (wrapped in a
lengthy rant about Windows development) here.
- the osgDB::fopen is only the tip of the iceberg
- the whole thing is futile if you need to rely on prebuild 3rdparty
binaries as chances are high the patch version of VS 2008 and its
runtime does not match with what the 3rdparty binaries were build with
(try to have a look at the WinSxS and count the variants of VS90_*)
- if you are build your own 3rdparty binaries you need to match exactly
the same binding settings otherwise VisualStudio 2008 will actually do
mixed bindings - thus the one for the actual binary plus the one from
the dependencies. You can nicely look at this behaviour using the
3rdparty package kindly provided on the OSG website plus using the _BIND
- build the jpeg plugin and look at the osgdb_jpg.intermediate.manifest
created in the binary tree - it will have bindings to two different C
runtimes. Intermediate manifests are forcibly linked into your binaries.
- Microsoft actually also introduced bind redirection with manifests but
for all of our sanity this would go to far to explain here now and after
all its sounds also more like a workaround.
- In relation to the COLLADA 2.2 or 2.2.1 discussion - after being
sensitised on that matter with the other problems I had - I can only say
the COLLADA 2.2.1 trunk (and the 2.2 package) is the most eclectic mix
of binaries and should not be used with VS 2008. There are VS8, VS9 and
VS2003SP1 libraries all nicely bundles together. Zlib being linked
against the latter 7.1 compiler thus interfering with the dependecy of
the libpng provided in the 3rdparty binary. Crossing fingers to run an
executable with this is probably not enough.
So I resorted finally to the solution Christian was suggesting earlier -
shipping the VisualStudio 2008 SP1 redistributable (adding ~4MByte to an
normally 5MByte installer) with my application. Its the only way to get
all redirected manifests to point to the one and true VC runtime. Oh,
and if you do so don't put the redist manifests and DLLs in the binary
directory as they will break everything again. So finally Microsoft
managed to let us C++ developer feel like C# or Java developers - don't
forget that runtime of yours.
Cheers,
Hartmut
Jean-Sébastien Guay wrote:
Hi Robert, Hartmut,
The changes seem sound, I'd like to see if there are any side effects
though, so I'll test the changes in a fresh build linked to a small
application tomorrow. I'll let you know what I find out.
Change #1 (refer to the original e-mail from Hartmut) is ok, it's a
small function that will now be inlined instead of in the DLL,
preventing the fopen call being made in a different DLL context than the
fclose call. The penalty for such a small function is small, so I don't
see a problem. Perhaps a comment could be added explaining why this
function is inline while all others are extern...
Change #2 is interesting. Trying to be diligent (since /a priori/ I
didn't know anything about these settings), I looked up the defines
Hartmut added, and found this:
http://blogs.msdn.com/vcblog/archive/2008/05/15/vc-runtime-binding.aspx
It seems that the behavior for resolving the C++ runtime version
dependencies changed between VC2005 and VC2008. The defines Hartmut
added just bring VC2008's settings back to VC2005 defaults. So in
theory, it should have no effect for VC2005 either since the default was
already set that way.
I wonder what the implication on user applications will be, considering
the information on that page. But I guess if the developer ships the VC
runtime DLLs (that he compiled the app with) with his application, or
the user has that version or newer of the VC runtime installed, it
should be ok. That's what happens for VC2005 after all.
It's true that perhaps those defines should be optional (I would make
them default to on, as it will probably not change anything for most
users but those who will have the same problems as Hartmut had will want
to turn it on - people who want to turn it on will be few and will know
the reasons why). Perhaps that should be added to the patch before final
submission.
I've compiled OSG and an application I was working on with these
changes, and didn't get any adverse change in behavior. Of course, I'm
still using VC2005. Perhaps we could wait for someone else using VC2008
to test as well, but as I said, I think the changes are OK even in that
context.
Hope this helps,
J-S
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
