Chris,
Chris 'Xenon' Hanson wrote:
Cory Riddell wrote:
I started out thinking this is the obvious answer, but the more I think
about it, I'm not so sure. For example, OSG uses OpenGL from operating
system libraries or libraries supplied by my video card maker. These may
not even be compiled by a Microsoft compiler and there certainly isn't
any way for me to recompile them. This makes me think that it doesn't
really matter.
I would like to understand what the problem is with mixing object files
built against different versions of library files.
In this case, I believe it is acknowledged that the new patch does want stuff
recompiled. I don't know the details exactly, but it's using a different C/C++ runtime
(CRT) library which is causing havoc for developers.
Libraries like OpenGL do not utilize the C/C++ runtime, rather they do without (things
like streams, or stdio) use the core Windows Win32 API functions. Most Windows system
libraries will be this way. Third-party libraries, especially those with poratability in
mind, avoid system-specifc APIs like Win32 wherever possible in favor of the portable
C/C++ runtime. but that means they are dependent on linking with the right version of CRT.
Ok, this actually makes a lot of sense to me. Now I wonder how I can
figure out if a particular library does depend on the CRT library. I've
had some luck doing:
dumpbin /directives FOO.lib
but I'm thinking there is likely a better way.
For the OSG stuff posted on the downloads page for Microsoft systems,
versions 2.8.0, 2.81, and 2.8.2 are made for the .762 version of the
CRT and I'm guessing 2.8.3 will require .4053. You know, I'm surprised
any software ever works.
Cory
|
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
