Re: [osg-users] bugfix osgDB cross-DLL allocation problem
Hi Hartmut, it will have bindings to two different C runtimes. Intermediate manifests are forcibly linked into your binaries. What? I thought the runtime version issues only affected the C++ runtime, not the C runtime? At least with VC++ 2005, pure-C libraries had no issues with runtime versions... We have not moved to VC++ 2008 yet, but this development might make us consider waiting to see if the situation will be better in the next version and just skipping this one... 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. Or just include a note in the documentation that the runtime must be installed, or make a check to make sure it has already been installed before... Why bundle the runtime in each version when it just needs to be installed once (or upgraded when a new SP comes out)? And it's possible that the user has had to install it before for another application. I'm not saying this is not a problem, but there are solutions that don't force you to bloat your installer. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] bugfix osgDB cross-DLL allocation problem
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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] bugfix osgDB cross-DLL allocation problem
Hi JS, Thanks for the testing. The fact that Change #1 does change a function to become a inline implementation does change the ABI, not a problem from 2.9.x but does rule out being part of OSG-2.8.1 as so far there has been not ABI breaks despite all the bug fixes. Feedback from others please :-) Robert. On Mon, May 11, 2009 at 3:19 PM, 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 > -- > __ > Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com > http://www.cm-labs.com/ > http://whitestar02.webhop.org/ > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] bugfix osgDB cross-DLL allocation problem
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 -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] bugfix osgDB cross-DLL allocation problem
Hi Robert, Hartmut submitted some Windows specific build changes to the OSG and called for feedback, and I follow up with a request for feedback on these changes. Alas not a single reply I've been very busy on my side so I haven't followed this thread as much as I would have liked. 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. Sorry for the delay, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] bugfix osgDB cross-DLL allocation problem
Hi All, Hartmut submitted some Windows specific build changes to the OSG and called for feedback, and I follow up with a request for feedback on these changes. Alas not a single reply Any chance that Windows experts you review Hartmut's changes. I can't personally make a decision on this topic as I don't have Windows or Windows build expertise. I've been holding back from making the the next OSG-2.8.1 rc so I could get feedback on whether it's appropriate to merge the changes so would very much appreciate some feedback so we can get OSG-2.8.1 completed. Thanks in advance, Robert. On Thu, May 7, 2009 at 5:13 PM, Robert Osfield wrote: > Hi Hartmut & Windows users, > > Has anyone tested Hartmut changes? Hartmut changes look like there > would be appropriate for merging into the OSG-2.8, but I won't do this > till we're absolutely sure there is no collateral damage. > > Harmut could provide a bit more information about why these changes > are required. For instance how do the problems manifest themselves. > The reason I'd like to get this clarified is there are lots of Windows > users who've tested/are using OSG-2.8.0 and haven't reported problems. > Is it only particular usage models that reveal problems? > > Thanks in advance for feedback, ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] bugfix osgDB cross-DLL allocation problem
Hi Hartmut & Windows users,
Has anyone tested Hartmut changes? Hartmut changes look like there
would be appropriate for merging into the OSG-2.8, but I won't do this
till we're absolutely sure there is no collateral damage.
Harmut could provide a bit more information about why these changes
are required. For instance how do the problems manifest themselves.
The reason I'd like to get this clarified is there are lots of Windows
users who've tested/are using OSG-2.8.0 and haven't reported problems.
Is it only particular usage models that reveal problems?
Thanks in advance for feedback,
Robert.
On Thu, May 7, 2009 at 1:01 AM, Hartmut Seichter
wrote:
>
> Dear all,
>
> hunting around for a while with plain VMware images and rebuilding
> everything constantly I drilled down to the cause of the problem which I
> reported earlier which turns out to be twofold:
>
> 1) osgDB::fopen is opening a file (fopen) in the scope of osgDB dll and
> various plugins and also osgWidgets close files via the ANSI-C fclose (in
> the scope of the plugin) - this works fine for most OSes just not Windows
> and OS X. My fix is to inline the proxied version of fopen because otherwise
> osgDB needs to provide the whole set of C file operation functions.
>
> 2) Visual Studio 2008 is defaulting to link to the lowest common denominator
> of the runtime which is something like 9.0.22*** - however all known
> versions of VS 2008 (with or without SP or FeaturePack) ship with a
> redistributable with version 9.0.30*** - thus welcome to SxS hell. The
> introduced defines should work on both VS 2008 with and without SP1 (there
> was a bug ignoring the catch all version _VC_LIBS_) - it should have only an
> effect in VS 2005 and 2008 - maybe there should be an CMake option() around
> the defines as I could imagine some people want this exact behaviour.
>
> Please test and comment (the patch is against the 2.8 branch but should be
> easy to port into the trunk)
>
> Cheers,
> Hartmut
>
> --
> Dr. Hartmut Seichter
> PhD (HKU), Dipl.-Ing. (BUW)
> Post-Doctoral Fellow, HIT Lab NZ
> +64 3 364 3078
> http://www.hitlabnz.org/people/hse25
>
>
>
>
>
> Index: CMakeLists.txt
> ===
> --- CMakeLists.txt (revision 10140)
> +++ CMakeLists.txt (working copy)
> @@ -186,6 +186,8 @@
> # More MSVC specific compilation flags
> ADD_DEFINITIONS(-D_SCL_SECURE_NO_WARNINGS)
> ADD_DEFINITIONS(-D_CRT_SECURE_NO_DEPRECATE)
> + ADD_DEFINITIONS(-D_BIND_TO_CURRENT_CRT_VERSION=1)
> + ADD_DEFINITIONS(-D_BIND_TO_CURRENT_MFC_VERSION=1)
> ENDIF(MSVC)
>
> #needed for net plugin
> Index: include/osgDB/FileUtils
> ===
> --- include/osgDB/FileUtils (revision 10140)
> +++ include/osgDB/FileUtils (working copy)
> @@ -14,6 +14,7 @@
> #ifndef OSGDB_FILEUTILS
> #define OSGDB_FILEUTILS 1
>
> +#include
> #include
>
> #include
> @@ -38,8 +39,17 @@
>
> // Overload of the standard fopen function. If OSG_USE_UTF8_FILENAME is
> defined,
> // filename will be expanded from UTF8 to UTF16 and _wfopen will be called.
> -extern OSGDB_EXPORT FILE* fopen(const char* filename, const char* mode);
> +//extern OSGDB_EXPORT FILE* fopen(const char* filename, const char* mode);
>
> +inline FILE* fopen(const char* filename, const char* mode)
> +{
> +#ifdef OSG_USE_UTF8_FILENAME
> + return ::_wfopen(convertUTF8toUTF16(filename).c_str(),
> convertUTF8toUTF16(mode).c_str());
> +#else
> + return ::fopen(filename, mode);
> +#endif
> +}
> +
> // Make a new directory. Returns true if directory exists or was created.
> extern OSGDB_EXPORT bool makeDirectory( const std::string &directoryPath );
>
> Index: src/osgDB/FileUtils.cpp
> ===
> --- src/osgDB/FileUtils.cpp (revision 10140)
> +++ src/osgDB/FileUtils.cpp (working copy)
> @@ -98,15 +98,6 @@
> #endif
> }
>
> -FILE* osgDB::fopen(const char* filename, const char* mode)
> -{
> -#ifdef OSG_USE_UTF8_FILENAME
> - return ::_wfopen(convertUTF8toUTF16(filename).c_str(),
> convertUTF8toUTF16(mode).c_str());
> -#else
> - return ::fopen(filename, mode);
> -#endif
> -}
> -
> bool osgDB::makeDirectory( const std::string &path )
> {
> if (path.empty())
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] bugfix osgDB cross-DLL allocation problem
Dear all,
hunting around for a while with plain VMware images and rebuilding
everything constantly I drilled down to the cause of the problem which I
reported earlier which turns out to be twofold:
1) osgDB::fopen is opening a file (fopen) in the scope of osgDB dll and
various plugins and also osgWidgets close files via the ANSI-C fclose
(in the scope of the plugin) - this works fine for most OSes just not
Windows and OS X. My fix is to inline the proxied version of fopen
because otherwise osgDB needs to provide the whole set of C file
operation functions.
2) Visual Studio 2008 is defaulting to link to the lowest common
denominator of the runtime which is something like 9.0.22*** - however
all known versions of VS 2008 (with or without SP or FeaturePack) ship
with a redistributable with version 9.0.30*** - thus welcome to SxS
hell. The introduced defines should work on both VS 2008 with and
without SP1 (there was a bug ignoring the catch all version _VC_LIBS_) -
it should have only an effect in VS 2005 and 2008 - maybe there should
be an CMake option() around the defines as I could imagine some people
want this exact behaviour.
Please test and comment (the patch is against the 2.8 branch but should
be easy to port into the trunk)
Cheers,
Hartmut
--
Dr. Hartmut Seichter
PhD (HKU), Dipl.-Ing. (BUW)
Post-Doctoral Fellow, HIT Lab NZ
+64 3 364 3078
http://www.hitlabnz.org/people/hse25
Index: CMakeLists.txt
===
--- CMakeLists.txt (revision 10140)
+++ CMakeLists.txt (working copy)
@@ -186,6 +186,8 @@
# More MSVC specific compilation flags
ADD_DEFINITIONS(-D_SCL_SECURE_NO_WARNINGS)
ADD_DEFINITIONS(-D_CRT_SECURE_NO_DEPRECATE)
+ ADD_DEFINITIONS(-D_BIND_TO_CURRENT_CRT_VERSION=1)
+ ADD_DEFINITIONS(-D_BIND_TO_CURRENT_MFC_VERSION=1)
ENDIF(MSVC)
#needed for net plugin
Index: include/osgDB/FileUtils
===
--- include/osgDB/FileUtils (revision 10140)
+++ include/osgDB/FileUtils (working copy)
@@ -14,6 +14,7 @@
#ifndef OSGDB_FILEUTILS
#define OSGDB_FILEUTILS 1
+#include
#include
#include
@@ -38,8 +39,17 @@
// Overload of the standard fopen function. If OSG_USE_UTF8_FILENAME is
defined,
// filename will be expanded from UTF8 to UTF16 and _wfopen will be called.
-extern OSGDB_EXPORT FILE* fopen(const char* filename, const char* mode);
+//extern OSGDB_EXPORT FILE* fopen(const char* filename, const char* mode);
+inline FILE* fopen(const char* filename, const char* mode)
+{
+#ifdef OSG_USE_UTF8_FILENAME
+ return ::_wfopen(convertUTF8toUTF16(filename).c_str(),
convertUTF8toUTF16(mode).c_str());
+#else
+ return ::fopen(filename, mode);
+#endif
+}
+
// Make a new directory. Returns true if directory exists or was created.
extern OSGDB_EXPORT bool makeDirectory( const std::string &directoryPath );
Index: src/osgDB/FileUtils.cpp
===
--- src/osgDB/FileUtils.cpp (revision 10140)
+++ src/osgDB/FileUtils.cpp (working copy)
@@ -98,15 +98,6 @@
#endif
}
-FILE* osgDB::fopen(const char* filename, const char* mode)
-{
-#ifdef OSG_USE_UTF8_FILENAME
-return ::_wfopen(convertUTF8toUTF16(filename).c_str(),
convertUTF8toUTF16(mode).c_str());
-#else
-return ::fopen(filename, mode);
-#endif
-}
-
bool osgDB::makeDirectory( const std::string &path )
{
if (path.empty())
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
