MSVC 7.1: Clashing runtime libs
by Kevin Bluck · in Torque Game Engine · 07/13/2005 (5:06 pm) · 7 replies
I noticed that /NODEFAULTLIB was set for LIBC/LIBCD in the project. This immediately piqued my interest; it's extremely rare to have a good reason for doing that.
I discovered a couple of things:
It appears that runtime libraries are different between various projects in the solution. Some are set to single threaded, some to multithreaded, some to multithreaded DLL. This is a Bad Thing in MSVC-land. All parts of a given build configuration should be using the same runtime library setting, or some extremely bizarre runtime problems can result.
I presume this is the reason for the /NODEFAULTLIB setting, to suppress the resulting warning LNK4098 'defaultlib "library" conflicts with use of other libs; use /NODEFAULTLIB:library'. That warning is poorly phrased; undoubtedly the individual was just following instructions, but suppressing the default lib merely conceals the real problem, which is that different modules are using different runtimes.
See: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/lnk4098.asp
I changed the various components to use the same setting. /MT and MTd respectively, to be exact. I then discovered that the ogg and vorbis libs were being supplied as prebuilt static libs. This puzzled me; is there any particular reason that the source for vorbis is not being built like the other included third-party libs? This seems like a booby-trap for the unwary developer, as you have to know under which runtime these libs were built.
I set up the source for ogg 1.1.1 and vorbis 1.1.2, turned the runtimes to match, and got a clean build with no linker warnings and no need to suppress any default libs. It wasn't difficult to massage those two libs into a form suitable for inclusion in the TGE tree. I can provide those trees if anyone at GG is interested, but its not hard to figure out. Basically keep only the include, lib, src folders without the CVS/makefile cruft, and transfer the build files to the appropriate place in torque, with suitable path modifications. Took me about 20 minutes.
TSE seems to have the same issues.
These issues are subtle, but nevertheless significant. I think they're worth fixing in the build configuration for VC6/VC7 before the next SDK release. I would be happy to provide a patch, except that I do not have VC6 to make the .dsp/.dsw files, and it looks to me like the .sln/.vcproj files are imported from the VC6 files. So I doubt it would be much help.
Thanks,
--- Kevin
I discovered a couple of things:
It appears that runtime libraries are different between various projects in the solution. Some are set to single threaded, some to multithreaded, some to multithreaded DLL. This is a Bad Thing in MSVC-land. All parts of a given build configuration should be using the same runtime library setting, or some extremely bizarre runtime problems can result.
I presume this is the reason for the /NODEFAULTLIB setting, to suppress the resulting warning LNK4098 'defaultlib "library" conflicts with use of other libs; use /NODEFAULTLIB:library'. That warning is poorly phrased; undoubtedly the individual was just following instructions, but suppressing the default lib merely conceals the real problem, which is that different modules are using different runtimes.
See: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/lnk4098.asp
I changed the various components to use the same setting. /MT and MTd respectively, to be exact. I then discovered that the ogg and vorbis libs were being supplied as prebuilt static libs. This puzzled me; is there any particular reason that the source for vorbis is not being built like the other included third-party libs? This seems like a booby-trap for the unwary developer, as you have to know under which runtime these libs were built.
I set up the source for ogg 1.1.1 and vorbis 1.1.2, turned the runtimes to match, and got a clean build with no linker warnings and no need to suppress any default libs. It wasn't difficult to massage those two libs into a form suitable for inclusion in the TGE tree. I can provide those trees if anyone at GG is interested, but its not hard to figure out. Basically keep only the include, lib, src folders without the CVS/makefile cruft, and transfer the build files to the appropriate place in torque, with suitable path modifications. Took me about 20 minutes.
TSE seems to have the same issues.
These issues are subtle, but nevertheless significant. I think they're worth fixing in the build configuration for VC6/VC7 before the next SDK release. I would be happy to provide a patch, except that I do not have VC6 to make the .dsp/.dsw files, and it looks to me like the .sln/.vcproj files are imported from the VC6 files. So I doubt it would be much help.
Thanks,
--- Kevin
About the author
#2
How did you choose /MT and /MTd versus the DLL versions of the libraries?
I was about to change all the projects to the multithreaded DLL libraries given that there are some DLLs being built.
Thanks
Todd
10/05/2005 (12:34 pm)
Hey Kevin,How did you choose /MT and /MTd versus the DLL versions of the libraries?
I was about to change all the projects to the multithreaded DLL libraries given that there are some DLLs being built.
Thanks
Todd
#3
Generally speaking, the DLL libs are only necessary when the DLLs are interacting with the C runtime in a cooperative way, such as memory being allocated in one module and freed in another. The "basic" DLLs associated with torque, namely the GLtoDX stuff and OpenAL, don't seem to suffer from this sort of interdependence. Win32 API calls are always safe regardless of library thanks to Microsoft magic.
That said, using the DLL version would likely be safer for the "general" case where unknown DLLs may end up being incorporated. It also has the advantage of not statically linking the runtime into every DLL. It would, however, require additional steps in the product installer to ensure the target systems have the necessary runtime DLLs.
10/05/2005 (2:15 pm)
I chose that mainly because that's what the majority of projects were already set to.Generally speaking, the DLL libs are only necessary when the DLLs are interacting with the C runtime in a cooperative way, such as memory being allocated in one module and freed in another. The "basic" DLLs associated with torque, namely the GLtoDX stuff and OpenAL, don't seem to suffer from this sort of interdependence. Win32 API calls are always safe regardless of library thanks to Microsoft magic.
That said, using the DLL version would likely be safer for the "general" case where unknown DLLs may end up being incorporated. It also has the advantage of not statically linking the runtime into every DLL. It would, however, require additional steps in the product installer to ensure the target systems have the necessary runtime DLLs.
#5
One more (probably silly) question for this....
I went to get the latest ogg, vorbis, theora libs and the latest ones on the site do not appear to be as up to date as the ones in Torque CVS. Specifically, the header files for ogg 1.1.1 and vorbis 1.1.1 have a version id that is much earlier than the 9/9/05 date stamp in the corresponding header files in the CVS.
Thanks again.
Todd
10/09/2005 (8:04 am)
Kevin,One more (probably silly) question for this....
I went to get the latest ogg, vorbis, theora libs and the latest ones on the site do not appear to be as up to date as the ones in Torque CVS. Specifically, the header files for ogg 1.1.1 and vorbis 1.1.1 have a version id that is much earlier than the 9/9/05 date stamp in the corresponding header files in the CVS.
Thanks again.
Todd
#6
CVS headers may have gotten clobbered from getting checked into/out of GG's CVS - make sure that the person noted there is a real developer from those projects.
10/09/2005 (10:51 am)
That probably belongs in a new thread.CVS headers may have gotten clobbered from getting checked into/out of GG's CVS - make sure that the person noted there is a real developer from those projects.
Associate Kyle Carter